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PREFACE  1 

Preface 

|  This  manual  describes  Soar,  version  4.  This  is  the  version  of  Soar  currently  available  (January,  1986)  in 

|  Common  Lisp.  Fmnz-Lisp.  Interlisp  and  Z  eta- Lisp. 

I 

Soar  is  an  architecture  for  problem  solving  and  learning,  based  on  heuristic  search  and  chunking.  Soar  is 
!  embedded  in  a  production-system  architecture  —  a  modified  version  of  0ps5  —  where  all  the  volatile 

short-term  information  is  held  in  working  memory  and  all  the  fixed  long-term  knowledge  is  encoded  as 
productions.  Chapter  1  is  an  overview  and  introduction  to  the  structure  of  the  Soar  architecture.  Chapters  2 
and  3  describe  the  nitty-gritty  of  working-memory  representation  and  production  representation  in  Soar. 
Chapter  4  describes  the  decision  scheme  that  determines  the  selection  of  problem  spaces,  states  and  operators. 
Chapter  5  gives  the  details  of  how  subgoals  are  automatically  created  and  terminated.  Chapter  6  describes  the 
default  processing  in  Soar,  that  is.  the  search-control  knowledge  that  comes  with  Soar.  Chapter  7  describes 
chunking,  the  learning  mechanism  in  Soar.  Chapter  8  is  a  short  tutorial  that  describes  how  to  encode  goals, 
problem  spaces,  states,  operators,  and  evaluation  functions  using  the  Hight  Puzzle  as  an  example.  Chapter  9 
discusses  advanced  programming  topics.  Chapter  10  describes  the  global  variables  and  top-level  functions  of 
Soar.  Chapter  11  lists  all  of  the  error  and  warning  messages  generated  by  Soar  and  includes  some  hints  on 
correcting  difficult  bugs.  Chapter  12  describes  how  to  obtain  and  install  Soar  for  different  machines.  Chapter 
13  is  a  summary  of  benchmarking  runs  of  Soar  on  a  wide  variety  of  computers.  Chapter  14  contains  an 
annotated  bibliography  of  Soar  publications.  An  appendix  lists  all  of  the  default  productions  that  come  with 
Soar.  An  index  is  at  the  end  of  the  manual.  This  manual  does  not  attempt  to  substitute  for  the  general 
scientific  d  scriptions  of  Soar  provided  by  the  publications  listed  in  the  bibliography. 

Souris  the  result  of  joint  development  between  John  Laird,  Allen  Newell  and  Paul  Rosenbloom.  Credit  is 
due  to  Paul  Rosenbloom  and  Dan  Scales  for  implementing  parts  of  Soar  and  Ron  Saul  for  writing  the 
programs  that  convert  Soar  from  InterLisp  to  the  other  dialects.  A  note  of  appreciation  is  due  Lanny  Forgy 
for  creating  OpsS.  which  forms  the  backbone  of  the  production-system  interpreter  in  the  current 
implementation  of  Soar. 

I  would  like  to  thank  Allen  Newell.  Paul  Rosenbloom.  Jill  Fain.  Gregg  Yost,  Stephen  Smoliar.  Dan  Scales 

I 

and  David  Steicr  for  comments  on  earlier  drafts  of  this  manual. 

All  suggestions,  comments,  and  questions  concerning  this  manual  or  5onrshould  be  directed  to 
|  soar<&  hxs.cmu.edu  for  computer  net-mail  or 

John  K.  Laird,  Xerox  PARC.  3333  Coyote  Hill  Rd..  Palo  Mto.  CA.  94304. 
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1.  Introduction 

''Soar  is  an  architecture  for  general  intelligence  that  has  been  applied  to  a  variety  of  tasks:  many  of  the  classic 
artificial  intelligence  ( Al)  toy  tasks  such  as  the  Tower  of  Hanoi,  and  the  Blocks  World:  tasks  that  appear  to 
involve  complex,  non-search  reasoning,  such  as  syllogisms,  the  three  wise  men  puzzle,  and  sequence 
extrapolation:  and  large  tasks  requiring  expea-level  knowledge,  such  as  the  R1  computer-configuration  task. 
This  chapter  provides  a  brief  overview  of  the  Soar  architecture. 

In  Soar,  every  task  or  problem  is  formulated  as  heuristic  search  in  a  problem  space  to  achieve  a  goal.  A 
problem  space  consists  of  a  set  of  states  and  a  set  of  operators  that  transform  one  state  into  another.  Problem 
solving  is  the  process  of  moving  from  a  given  initial  state  in  the  problem  space  through  intermediate  states 
generated  by  operators  until  a  desired  state  is  reached  that  is  recognized  as  attaining  the  goal.  For  each  goal, 
there  is  always  a  single  current  problem  space,  state,  and  operator.  Ihe  current  problem  space,  state  and 
operator,  together  with  the  goal,  form  a  context.  Goals  (and  their  contexts)  can  have  subgoals  (and  associated 
contexts),  which  form  a  strict  goal-subgoal  hierarchy.  The  detailed  structure  of  these  objects  is  described  in 
Chapter  2. 

Throughout  the  search,  decisions  are  made  to  select  between  the  available  problem  spaces,  states,  and 
operators.  Every  problem-solving  episode  consists  of  a  sequence  of  such  decisions  and  these  decisions 
determine  the  behavior  of  the  system.  Problem  solving  begins  with  the  selection  of  a  problem  space  for  an 
existing  goal,  (  his  is  followed  by  the  selection  of  an  initial  state,  and  then  an  operator  to  apply  to  the  state. 
Once  the  operator  is  selected,  it  is  applied  to  create  a  new  state.  The  new  state  can  (but  need  not)  then  be 
selected,  and  the  process  repeats  as  a  new  operator  is  selected  to  apply  to  the  selected  state.  The  knowledge 
that  implements  a  task  —  suggests  feasible  problem  spaces,  creates  initial  states,  implements  operators  —  is 
collectively  called  task- implementation  knowledge.  All  standard  weak  methods  can  be  represented  as 
knowledge  to  control  the  selection  of  problem  spaces,  states  and  operators.  The  knowledge  that  controls  these 
decisions  is  collectively  called  search  control.  Problem  solving  without  search  control  is  quite  common, 
however  the  result  is  an  exhaustive  search  of  the  problem  space. 

Figure  1-1  shows  a  schematic  representation  of  the  decision-making  process.  To  bring  all  available  task- 
implementation  and  search-control  knowledge  to  bear  on  making  a  decision,  each  decision  involves  a 
monotonic  elaboration  phase.  During  the  elaboration  phase,  all  directly  available  knowledge  relevant  to  the 
current  situation  is  brought  to  bear.  Knowledge  that  is  not  directly  available,  but  can  be  extracted  by  search, 
can  be  brought  to  bear  only  in  subgoais.  The  directly  jvailablc  knowledge  in  Soar  is  represented  as 
productions.  Chapter  3  describes  the  language  for  specifying  productions  in  Soar.  Ihe  contexts  of  the  goal 
hierarchy  and  their  augmentations  serve  as  the  working  memory  for  these  productions.  Ihe  information 
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added  during  the  elaboration  phase  can  take  one  of  two  forms.  First,  existing  objects  may  have  their 
descriptions  augmented  with  new  or  existing  objects.  For  example,  a  new  state  can  be  created  that  is  the 
result  of  applying  the  current  operator  to  the  current  state.  Second,  data  structures  called  preferences  can  be 
created  that  assert  the  worth  of  an  object  for  a  role  in  a  context.  Each  preference  indicates  the  context  in 
which  it  is  relevant  by  specifying  the  goal,  problem  space  and  state. 


DECISION  1 


DECISION  2 


Elaboration 


Quiescence 


Decision 


DECISION  3 

X 


Preferences 

I 

Interpret  - 
Preferences 

I 

Impasse 

l 

Create 

Subgoal 


Replace 

Context 

Object 


Figure  1*1:  The  Soar  decision  cycle. 


On  each  cycle  of  the  elaboration  phase,  all  instantiations  of  satisfied  productions  fire  in  parallel.  When  the 
elaboration  phase  reaches  quiescence  —  no  more  productions  eligible  to  fire  —  a  fixed  decision  procedure  is 
run  that  integrates  the  preferences  provided  by  the  elaboration  phase  into  a  specific  decision.  The  decision 
procedure  is  described  in  detail  in  Chapter  4.  Starting  from  the  oldest  context,  the  decision  procedure  uses 
the  preferences  to  determine  if  the  current  problem  space,  state  and  operator  in  each  context  should  be 
changed.  If  sufficient  knowledge  is  available  during  the  search  to  determine  a  unique  decision,  the  search 
proceeds  unabated.  However,  in  many  cases,  the  directly  available  knowledge,  enr  aded  as  productions,  may 
be  insufficient.  When  this  occurs,  because  the  available  preferences  do  not  determine  a  unique,  uncontested 
change  in  a  context,  an  impasse  in  problem  solving  has  been  reached.  Four  types  of  impasses  can  arise:  tie 
(no  single  object  was  better  than  all  of  the  other  objects  competing  to  change  a  context),  conflict  (two  or  more 
objects  were  better  than  each  other  while  competing  to  change  a  context),  no-change  (the  elaborauon  phase 
ran  to  quiescence  without  suggesting  any  changes  to  the  contexts),  and  rejection  (all  competing  objects  were 
rejected,  including  the  one  currently  in  place). 
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Soar  creates  a  subgoal  (and  an  associated  context)  to  resolve  the  impasse.  Once  a  subgoal  is  created,  a 
problem  space  must  be  selected,  followed  by  an  initial  state,  and  then  an  operator.  If  an  impasse  is  reached  in 
any  of  these  decisions,  another  subgoal  will  be  created  to  resolve  it.  leading  to  the  hierarchy  of  goals  in  Soar. 
By  treating  an  impasse  as  a  subgoal,  the  full  problem-solving  power  of  Soarcan  be  brought  to  bear  to  resolve 
the  impasse,  creating  whatever  response  is  appropriate  for  the  particular  instance  of  the  impasse.  These 
subgoals  correspond  to  th'  full  variety  of  subgoals  created  in  standard  AI  systems.  This  ability  to  generate 
automatically  all  subgoals  in  response  to  impasses  and  to  open  up  all  aspects  of  problem-solving  behavior  to 
problem  solving  when  necessary  is  called  universal  subgoaling.  Chapter  5  gives  a  complete  description  of 
subgoal  creation  and  termination  in  Soar. 

\  subgoal  terminates  when  its  impasse  is  resolved.  For  example,  if  a  tie  impasse  arose,  it  will  terminate 
when  sufficient  preferences  have  been  created  so  that  a  single  object  dominates  the  others.  When  a  subgoal 
terminates,  all  augmentations  and  preferences  created  in  that  subgoal  that  are  not  connected,  directly  or 
indirectly,  to  a  prior  context  are  removed  from  working  memory.  Those  objects  that  are  not  removed 
constitute  the  results  of  the  subgoals. 

Default  knowledge  exists  in  Soar  to  cope  with  the  impasses,  if  no  additional  knowledge  is  available.  For 
some  impasses  this  involves  rejecting  a  prior  choice  in  the  context:  for  other  impasses  this  involves  searching 
for  knowledge  to  resolve  the  impasse.  Any  additional  non-default  knowledge  about  how  to  resolve  an 
impasse  dominates  the  default  knowledge  and  controls  the  problem  solving  in  the  subgoal.  The  different 
default  responses  to  impasses  arc  described  in  more  detail  in  Chapter  6. 

In  addition  to  general  problem  solving,  •Saw  also  supports  a  general  learning  mechanism  called  chunking. 
Chunking  occurs  as  a  byproduct  of  problem  solving  in  goals.  Whenever  a  goal  is  satisfied,  a  chunk  —  a 
production  —  is  created  that  can  generate  the  results  of  the  goal  when  a  similar  situation  recurs.  The  chunk's 
conditions  arc  based  on  the  working-memory  elements  that  existed  prior  to  the  goal  that  were  matched  by  the 
conditions  of  productions  that  fired  during  the  processing  of  the  goal.  The  chunk's  actions  arc  the  working- 
memory  elements  that  were  created  in  the  goal  that  arc  of  potential  use  in  the  supcrgoal.  The  complete  details 
of  chunking  arc  given  in  Chapter  7. 

Soar  is  meant  to  be  the  underlying  architecture  for  an  autonomous  intelligent  agent.  Its  behavior  is 
determined  by  the  knowledge  it  contains,  and  ideally  wc  should  be  able  to  describe  and  specify  its  behavior  in 
terms  of  the  knowledge  it  has  for  implementing  and  controlling  its  behavior.  However,  in  this  manual,  the 
viewpoint  of  the  user  as  programmer  is  taken  I  his  v  icw  is  more  standard  m  programming  manuals,  but  it  is 
not  the  "true"  point  of  view  for  .Soar  as  an  architecture  tor  general  intelligence. 
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2.  Data  Representation  in  Working  Memory 

Ihe  production-system  aspects  of  Soar  are  derived  from  Ops5.  and  as  such.  Soar  inherits  the  basic 
representational  scheme  of  working  memory  and  productions  provided  in  Ops5.  In  this  chapter,  we  start  with 
a  brief  review  of  the  representation  of  working  memory  in  OpsS.  pointing  out  the  differences  in  Soar.  Next, 
we  describe  how  Soar  uses  this  scheme  to  represent  structures,  such  as  goals,  problem  spaces,  states  and 
operators.  All  information  on  Ops5  in  this  and  the  following  chapters  is  based  on  the  OpsS  User  s  Manual 
(Forgy.  1981). 

2.1 .  Working  Memory  in  Ops5 

Working  memory  in  OpsS  is  a  multi-set  of  elements,  called  working- memory  elements.  Each  working- 
memory  clement  consists  of  a  class,  followed  by  a  set  of  attribute-  vaiue  pairs.  Kach  attribute  is  prefaced  by  a 

t.  A  template  for  a  working-memory  clement  is  as  follows: 

( class  t  attribute!  value  l  t  attribute!  value2  .  .  .) 

For  example,  a  blue  block  that  is  called  block3,  weighs  200  grams,  and  is  on  a  block  called  block  1  could  be 
represented  as 

(block  tname  block3  tcolor  blue  mass  200  tontop  blockl) 

Each  working-memory  clement  is  represented  internally  in  OpsS  as  a  single  data  structure.  When  a  working- 
memory  element  is  created  (added  to  working  memory)  it  is  assigned  a  unique  integer,  called  its  time-lag. 
These  time-tags  are  often  displayed  by  the  system  in  place  of  the  working-memory  element  when  describing 
sets  of  working-memory  elements  to  the  user.  The  function  wm  prints  the  working-memory  element  given  a 
time-tag  (see  Section  10.5.6). 

2.2.  Working  Memory  in  Soar 

Working  memory  in  Soar  is  a  set  and  not  a  multi-set  (a  change  from  OpsS).  There  is  only  one  copy  of  a 
working-memory  element  in  working  memory  at  a  time.  If  an  action  of  a  production  tries  to  add  an  existing 
element  to  working  memory,  it  has  no  effect. 

In  Soar,  there  are  two  different  types  of  data  representations  in  working  memory:  objects,  and  preferences. 
Both  of  these  are  realized  in  the  attribute-value  representation  scheme  of  OpsS.  However,  the  OpsS  scheme 
has  certain  restrictions  that  force  Soar  to  represent  objects  indirectly  in  another  attribute-value  scheme  on  top 
of  the  OpsS  scheme:  (1)  Soar  must  be  able  to  reference  each  individual  attribute  of  an  object  without 
accessing  the  others:  (2)  .Soar  must  be  able  to  have  multiple  values  for  the  same  attribute  of  an  object  (a 
simple  representation  of  sets):  (3)  multiple  productions  must  be  able  to  create  different  attributes  for  an 
object  in  parallel:  and  (4)  Soarallows  variables  to  match  attributes.  Each  working-memory  element  in  .Voaris 
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an  identifier-attribute-value  triple  (except  for  preferences  which  are  described  later).  The  class  name  of  the 
working-memory  element  in  Soar  always  ends  in  -info  (or  is  just  info).  These  working-memory  elements  are 
called  augmentations.  Each  augmentation  has  three  Ops5  attributes:  t identifier,  tattribute  and  tvalue.  To 
avoid  confusion,  wc  will  refer  to  the  attributes  of  an  OpsS  working-memory  elements  as  fields.  So,  in  the 
following  example,  there  are  three  fields:  identifier,  attribute  and  value.  The  identifier  is  B0003,  the  attributes 

are  name  and  color,  and  the  values  arc  block.)  and  blue  respectively. 

(block-info  tidentifier  80003  tattribute  name  tvalue  block3) 

(block-info  tidentifier  80003  tattribute  color  tvalue  blue) 


To  overcome  the  redundancy,  of  this  representation  scheme.  Soar  provides  many  functions  (essentially  pre- 
and  post-processors)  that  hide  the  OpsS  representation  by  supporting  a  new  notation  called  SP  (for  Soar 
production).  For  example,  the  above  two  working-memory  elements  would  be  represented  as  follows  in  SP 
notation: 

(block  80003  tname  block3  tcolor  blue) 

In  SP  notation,  an  object  begins  wich  a  class.  However,  this  class  name  is  the  OpsS  class  without  -info  (-info 
lets  the  user  know  when  he  is  dealing  w  ith  OpsS  working-memory  elements  instead  of  SP  objects).  The  SP 
class  is  translated  into  an  OpsS  class  using  the  association  list  in  the  global  variable  *sp-classes*.  All  classes 
not  occurring  in  the  list  have  -info  added  to  them.  Using  this  list,  some  OpsS  classes  can  be  represented  by 
many  SP  classes.  For  example,  gc.  goal,  context,  and  goal-context  are  all  translated  into  goal-context- info, 
while  object  is  translated  into  just  info.  Initially,  there  are  eleven  SP  classes  that  map  onto  seven  OpsS  classes. 

These  are  pre-defined  by  the  global  variable  *sp-classes*: 

((gc  .  goal-context-info)  (goal  .  goal-context- info) 

(context  .  goal -context- inf o)  (goal -context  .  goal -context-info) 
(problem-space  .  space-info)  (space  .  space-info) 

(state  .  state-info)  (operator  .  op-info)  (desired  .  desired-info) 
(evaluation  .  eval-info)  (object  .  info)) 


Following  the  class  is  the  identifier  (B0003  above).  In  SP  notation,  the  identifier  must  not  be  preceded  by 
the  attribute  tidentifier  because  a  working-memory  element  with  attribute  tidentifier  is  assumed  to  be  in 
OpsS  format.  The  identifier  should  always  be  a  gensymed  symbol,  such  as  G0023.  Following  the  identifier 
are  the  attribute-value  pairs.  Fach  of  these  pairs  is  an  augmentation,  a  separate  OpsS  working-memory 
element.  Thus,  no  single  working-memory  element  defines  all  of  the  features  of  an  object.  Instead,  the  object 
takes  its  definition  from  the  augmentations  that  contain  its  identifier. 

In  Soar,  the  identifier  is  just  an  arbitrary  gensym.  If  a  meaningful  label  is  desired  for  an  object,  it  should  be 
the  value  of  the  name  attribute.  I  he  tracing  facilities  will  use  the  atom  in  the  value  field  of  a  name 

augmentation  when  displaying  information.  1  his  makes  the  traces  much  more  readable.  For  example: 

(op-info  tidentifier  SO  0 12  tattribute  name  tvalue  conf  igure-backp 1 ane ) 
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This  would  be  printed  by  the  tracing  facility  as  configure- backplane. 

2.3.  Goal-contexts 

Problem  solving  in  Soar  is  controlled  by  goal-contexts.  There  is  a  strict  goal  hierarchy:  a  subgoal  is  only 
created  in  response  to  an  impasse  in  problem  solving  for  an  active  goal.  Each  individual  context  contains  four 
roles:  goal,  problem  space,  state  and  operator.  Ihe  combination  of  a  role  and  a  context  defines  a  unique  slot. 
The  object  occupying  the  goal  role  in  a  context  is  the  current  goal  for  that  context:  the  object  occupying  the 
problem-space  role  is  the  current  problem  space  for  that  context,  and  so  on.  A  goal-context  is  represented  in 
working  memory  by  three  augmentations  of  the  goal  identifier,  one  for  each  of  the  non-goal  slots.  These 
augmentations  are  of  class  goal-context-info.  (In  SP  format,  the  class  can  be  goal-context,  goal,  context  or 
gc.)  The  identifier  field  contains  the  identifier  of  the  goal,  the  attribute  field  contains  the  appropriate  role. 
The  value  field  contains  the  idenufier  of  the  object  that  is  current  for  that  slot.  The  value  of  a  slot  is  undecided 
if  no  object  has  been  selected  for  it.  There  is  one  and  only  one  goal-context-info  working-memory  element 
for  each  slot.  Only  the  decision  procedure  (to  be  defined  later)  modifies,  adds,  or  removes  these  working- 
memory  elements.  Producuons  cannot  create  working-memory  elements  of  the  goal-context-info  class  that 
have  attribute  problem-space,  state  or  operator. 

Below  is  an  example  of  the  working-memory  elements  that  define  a  goal-context  in  SP  format. 

(gc  G0001  tproblem-space  G0034  tstate  G0047  toperator  G0033) 

This  is  expanded  internally  to  three  working-memory  elements. 

(goal-context-info  tidentifier  G0001  tattribute  problem-space 
rvalue  G0034) 

(goal -context- info  tidentifier  G0001  tattribute  state  tvalue  G0047) 

(goal -context- info  tidentifier  G0001  tattribute  operator  tvalue  G0033) 

2.4.  Preferences 

Preferences  are  a  special  type  of  data  structure  in  Soar.  A  preference  is  an  assertion  of  the  relative  or 
absolute  worth  of  an  object  for  a  context  slot.  Each  preference  is  a  single  working-memory  element  that  is  of 
class  preference  (it  is  a  single  working-memory  element  in  OpsS  notation  and  also  SP  notation,  and  in  both  its 
class  is  preference).  Preferences  are  created  by  productions,  and  they  are  used  by  the  decision  procedure  to 
replace  an  object  in  a  slot.  Ihe  processing  of  preferences  by  the  decision  procedure  is  discussed  in  Chapter  4. 

The  fields  of  a  preference  are: 

object  This  is  the  identifier  of  the  object  that  ihe  preference  will  jffcct.  (In  SP  notation,  the 

tohject  preceding  the  identifier  is  optional  as  long  as  n  is  the  first  field  following  the 
class.) 
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role  This  is  the  name  of  the  role  that  the  object  will  play  in  the  context:  problem-space, 

state  or  operator. 

value  The  value  is  a  relative  or  absolute  evaluation  of  the  object  in  the  object  field.  These 

evaluations  arc  only  relevant  when  the  goal,  problem-space,  state  and  operator  fields 
correctly  match  the  current  context.  Two  of  the  values  (acceptable  and  reject) 
determine  whether  an  object  will  be  considered.  Three  of  the  values  (better, 
indifferent,  and  worse)  provide  a  comparison  of  an  object  to  another  object  (the 
reference  object).  The  remaining  values  equate  an  object  to  a  hypothetical  ideal  (best, 
indifferent,  worst).  I  here  is  another  value,  parallel,  which  permits  parallel  execution 
(see  Section  9.2).  The  exact  semantics  of  these  values  are  given  in  Section  4. 

reference  The  identifier  that  is  compared  to  the  object  field,  only  when  the  value  field  is 

indifferent,  better,  worse,  or  parallel. 

goal,  problem-space,  state,  and  operator 

These  fields  define  the  relevant  context  for  the  preference.  A  preference  is  only  used 
when  the  current  context  corresponds  to  the  context  defined  by  these  fields,  if  the 
value  of  one  of  these  fields  is  not  nil.  it  is  compared  to  the  value  in  the  corresponding 
slot  of  a  context.  If  all  of  the  non-nit  context  fields  of  the  preference  match  the 
identifiers  in  the  corresponding  slots  of  a  context,  the  preference  will  be  used  in 
determining  new  values  for  the  context. 


The  following  preference  is  for  an  operator  (x33)  that  has  been  determined  to  be  worse  than  another 
operator  (x32).  Since  the  operator  field  is  not  specified,  it  becomes  nil  and  the  operator  slot  is  not  tested  when 
determining  the  relevance  of  the  preference. 

(preference  ^object  x33  rrole  operator  rvalue  worse  reference  x32 
rgoal  g!4  rproblem-space  p34  rstate  slO) 


An  object  is  selected  for  a  role  in  a  context  only  if  there  exists  an  acceptable-preference  for  that  object. 
Thus,  the  acceptable-preferences  for  previously  selected  objects  provide  a  partial  history  of  changes  to  the 
context.  Below  is  a  short  list  of  some  of  the  information  that  is  accessible  via  acceptable-preferences. 

prior  state  The  acceptable-preference  for  the  current  state  contains  the  prior  state  in  the  state 

field. 

prior  operator  The  acceptable-preference  for  the  current  state  contains  the  prior  operator  in  the 
operator  field.  The  prior  operator  is  the  operator  used  to  create  the  current  state. 

result  An  acceptable-preference  for  the  state  role  that  contains  the  results  of  applying  the 

object  in  the  operator  field  to  the  object  in  the  state  field  (which  must  not  be 
undecided).  If  the  operator  field  is  nil  or  undecided,  then  it  is  not  a  result,  but  probably 
a  prior  state. 

initial  slate  An  acceptable-preference  for  the  state  role  that  contains  undecided  in  the  state  field, 
contains  the  initial  stales  of  the  problem  space. 
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3.  Productions 

The  operation  of  Soorconsists  of  a  sequence  of  decisions  with  each  resulting  in  a  change  to  the  goal-context 
stack.  A  decision  consists  of  the  elaboration  phase  followed  by  the  decision  procedure.  During  the 
elaboration  phase,  all  satisfied  productions  fire  in  parallel  (simulated).  This  continues  until  no  more 
productions  arc  satisfied.  The  decision  procedure  examines  preferences  and  modifies  the  context-stack. 
Processing  continues  by  returning  to  the  elaboration  phase.  The  details  of  the  decision  procedure  .ire 
described  in  Section  4. 

The  productions  in  Soorcan  be  written  exactly  like  OpsS  productions.  A  production  consists  old)  an  open 
parenthesis.  (2)  the  symbol  p.  (3)  the  name  of  the  production  (any  symbol  except  nil).  (4>  a  set  of  conditions. 
(5)  the  symbol  (6)  a  set  of  actions,  and  (7)  a  close  parenthesis.  This  production  format  is  called  P  (since 

these  productions  all  start  with  P).  Tor  example,  a  very  simple  P  format  production  is  shown  below 
(p  joe-production 

( goal -context- i nf o  tidentifier  <g>  tattribute  state  rvalue  <s>) 
(state-info  identifier  <s>  tattribute  hole-shape  tvalue  sx>) 
(state-info  tidentifier  <s>  tattribute  peg-shape  tvalue  <>  <x>) 

-  -  > 

(make  state-info  tidentifier  <s>  tattribute  fits?  tvalue  no)) 
Productions  can  also  be  written  in  SP  format,  which  makes  them  much  more  concise.  Tor  example,  the  above 

production  would  be  written  in  SP  format  as  follows: 

(sp  joe-production 
(gc  <g>  tstate  <s>) 

(state  <s>  thole-shape  <x>  tpeg-shape  <>  <x>) 

--> 

( state  <s>  tf  its?  no) ) 

3.1 .  Production  Conditions 

The  conditions  of  a  P  format  production  are  patterns  to  be  matched  against  the  elements  in  working 
memory.  Tach  condition  is  a  form  for  matching  a  working-memory  element.  In  Soar  a  condition  is  a  list, 
starting  with  a  class  name,  followed  by  a  set  of  attribute-value  pairs.  The  attributes  must  be  constants,  while 
the  class  name  must  be  a  constant  or  a  variable.  The  values  can  be  one  of  a  number  of  patterns.  A  condition 
is  satisfied  if  all  of  its  components  (class  and  fields)  can  be  consistently  matched  against  a  working-memory 
clement.  A  production  is  satisfied  if  all  of  its  conditions  are  satisfied  with  a  consistent  binding  for  all  of  the 
variables  that  appear  in  the  conditions.  A  production  nistanuanon  is  the  set  of  working-memory  elements 
that  satisfy  the  production. 

To  simplify  the  matching  of  preferences  that  arc  relevant  to  a  context,  there  is  a  special  case  for  matching 
conditions  that  describe  prclcrcnccs.  \  preference  is  relevant  to  a  context  cither  if  the  values  in  its  context 
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fields  match  the  values  of  the  appropriate  slots  or  are  nil.  Therefore,  a  preference  condition  will  match  a 
preference  in  working  memory  if  the  values  of  the  context  fields  of  the  working-memory  element  either 
match  the  values  bound  to  the  variables  in  the  preference  or  are  nil  (nil  fields  are  not  show  in  working- 

memory  elements).  For  example: 

(sp  x 

(gc  <g>  tproblem-space  <p>  tstate  <s>) 

(preference  <x>  trole  operator  tvalue  acceptable 
tgoal  <g>  tproblem-space  <p>  tstate  <s>) 

--> 

( action  .  .  .  ) 
will  match 

(gc  gOOOl  tproblem-space  p0003  tstate  s0050) 

(preference  o0044  trole  operator  tvalue  acceptable 
tproblem-space  p0003) 


All  of  the  conditions  of  a  production  should  be  linked,  via  augmentations  and  preferences,  to  one  of  the 
goal-context-infos  of  the  production.  Augmentations  arc  one-way  links,  from  the  the  identifier  to  the  value. 
Preferences  are  one-way  links,  from  the  context  fields  (ail  must  be  present  or  nil)  to  the  object.  If  all 
conditions  are  not  linked,  a  warning  is  printed  when  the  production  is  compiled. 


3.1.1.  Variables 

A  variable  is  a  symbol  that  begins  with  a  <,  ends  with  a  >.  and  contains  an  alphanumeric  symbol  in  between. 
For  a  production  to  be  satisfied,  all  occurrences  of  the  same  variable  must  match  the  same  symbol  or  number. 
Two  different  variables  can  match  the  same  symbol  unless  there  is  an  explicit  test  that  they  are  not  equal 
(using  <». 


3.1.2.  Disjunctions  of  constants 

If  a  set  of  values  are  contained  with  the  symbols  <<  and  >>.  the  condition  will  match  a  working-memory 

element  with  any  of  those  symbols.  Variables  cannot  occur  within  a  disjunction,  nor  can  a  disjunction  appear 

in  a  negated  condition.  There  must  be  spaces  separating  both  <<  and  »  from  the  symbols  in  between  them. 
<<  red  blue  >> 

would  match  either  red  or  blue. 

3.1.3.  Predicates 

There  are  six  predicates  that  can  precede  constant  or  variable:  <>.<  =  >.<.<  =  ,>  =  .>.  For  example:  <> 
<a>.  <>  means  not  equal  and  will  match  anything  except  the  constant  or  variable  immediately  following  it. 
<  =  >  means  same  type  and  will  match  any  symbol  that  is  the  same  type  (numeric  or  svmbolic)  as  the  constant 
or  variable  immediately  following  it.  Similarly.  <  is  less  than.  <  =  is  less  than  or  equal.  >=  is  greater  than  or 
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equal,  and  >  is  greater  than. 

3.1.4.  Conjunction 

lo  signify  conjunctive  combinations  of  tests  for  a  single  field,  the  tests  are  contained  within  {  and  }.  Lor  a 

match  to  occur,  all  tests  within  the  brackets  must  succeed. 

{  <  50  >  20  <>  < x >  <y>  } 

In  this  example,  a  match  would  occur  only  if  the  value  is  less  than  50.  greater  than  20.  not  equal  to  the  value 
of  <x>  in  other  conditions  and  equal  to  <y>  in  other  conditions. 

3.1.5.  Negated  conditions 

In  addition  to  the  positive  tests  for  elements  in  working  memory,  conditions  can  also  test  for  the  absence  of 
patterns.  A  condition  preceded  by  is  called  a  negated  condition  and  will  be  satisfied  only  if  there  docs  not 
exist  a  working-memory  clement  consistent  with  its  tests  and  variable  bindings.  A  negated  condition  can  not 
include  a  disjunction,  such  as  <  <  a  b  c  >>. 

3.2.  Production  Actions  and  Functions 

If  all  of  the  conditions  of  a  production  are  satisfied  (with  consistent  variable  bindings),  the  actions  of  the 
production  will  be  performed.  One  significant  change  from  OpsS  is  that  a  variable  that  appears  only  in  the 
action  of  a  production  will  automatically  be  bound  to  a  new  gensymed  symbol  (starting  with  the  first  letter  of 
the  variable,  e.g..  <s>  might  be  bound  to  sl375).  This  symbol  will  be  used  for  all  occurrences  of  the  variable 
in  the  action.  I'his  convention  eliminates  the  need  for  most  calls  to  the  bind  action. 

Productions  create  preferences  and  augmentations  of  current  objects  by  creating  new  working-memory 
elements.  Logically,  all  creations  occur  in  parallel  and  all  satisfied  productions  fire  in  parallel,  with  the  new 
working-memory  elements  being  added  during  the  same  production  cycle.  The  only  ordering  of  actions  is 
between  multiple  writes  and  accepts  within  a  single  production.  Productions  cannot  remove  or  modify 
working-memory  elements.  A  production  should  not  create  a  working-memory  clement  that  will  lead  to  a 
new  instantiation  of  that  same  production  because  this  will  lead  to  an  infinite  loop.  A  production  should  only 
create  working-memory  elements  that  arc  linked  —  v  ia  the  identifier  for  augmentations,  and  the  context  fields 
for  preferences  to  identifiers  bound  —  to  variables  in  the  conditions  of  the  production.  If  this  is  not  so.  a 
warning  is  printed  when  the  production  is  compiled. 

Below  arc  the  available  production  actions.  In  the  function  definitions,  urg*  means  that  any  number  of 
arguments  (including  zero)  can  be  given. 

Bind  urg/  c jrg?  Binds  the  value  for  orgJ  to  urg/.  Irg/  must  be  a  variable.  IrgJ  can  be  a  previously 
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bound  variable,  a  constant  or  an  action-function  such  as  compute  or  accept. 

(bind  sinput>  (accept)) 

Call2  F  arg*  Applies  function  F  to  arguments  arg*.  F  and  arg*  can  be  variables,  bound  to 

appropriate  values.  This  is  prov  ided  so  that  the  actions  of  productions  can  control 
some  of  the  top-level  user  functions  such  as  watch,  user-select  dccidc-tracc.  and  learn. 
( cal  1 2  watch  2 ) 

Halt  Stops  the  execution  of  Soar. 

(halt) 

Make  Adds  to  working  memory  the  instantiated  pattern  that  follows  it. 

(make  state-info  tidentifier  <s>  tattribute  color 
rvalue  blue) 

Tabstop  argl  Binds  the  current  tabstop  being  used  by  watch  0  to  the  variable  argl. 

(tabstop  <tab>) 

(writel  (tabto  <tab>)  <o>  |x|) 

If  <tab>  is  bound  to  3  and  <o>  is  bound  to  4.  the  result  is: 

4  x 

Writel  arg *  Writes  its  arguments  with  blanks  in  between. 

(writel  (tabto  <tab>)  <o>  |x|) 

If  <tab>  is  bound  to  3  and  <o>  is  bound  to  4.  the  result  is: 

4  x 

Write2  arg*  Performs  the  same  tuncuon  as  write  except  that  spaces  are  not  automatically  inserted 
between  atoms. 

(write2  (tabto  <tab>)  <o>  |x|) 

If <tab>  is  bound  to  3  and  <o>  is  bound  to  4.  the  result  is: 

4x 

Below  are  the  functions  that  can  be  called  within  the  actions. 

Accept  Suspends  Soar  as  it  waits  for  the  user  to  type  in  an  atom.  The  result  is  that  atom, 

(state  tidentifier  <s>  tattribute  input 
tvalue  (accept)) 

Compute  Evaluates  arithmetic  expressions  using  the  following  five  operators:  +  (addition).  - 

(subtraction),  *  (multiplication).  //  (division),  and  \\  (modulus).  Only  numbers  and 
variables  bound  to  numbers  can  be  used  in  expressions.  The  expressions  are  evaluated 
using  standard  infix  notation,  but  there  is  no  operator  precedence.  The  operators  are 
evaluated  right  to  left,  except  when  overridden  by  parentheses. 

(state  tidentifier  <s>  tattribute  sum 
tvalue  (compute  <x>  +•  <y>)) 

(state  tidentifier  <s>  tattribute  product-sum 

tvalue  (compute  (<v>  +  <w>)  •  (<x>  +  <y>))) 
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Crlf  A  special  function  that  can  be  called  within  any  of  the  write  actions.  It  takes  no 

arguments  and  forces  a  new  line  at  its  position  in  the  write  action. 

(writel  < x >  (crlf)  <y>) 

Tabto  A  special  function  that  can  be  called  within  any  of  the  write  actions.  It  takes  one 

argument  that  is  a  column  number,  either  a  number,  or  a  variable  bound  to  a  number. 
It  modifies  the  write  so  that  it  begins  printing  at  the  column  given  as  its  argument, 
(writel  <x>  (tabto  <col>)  <y>) 

3.3.  SP  Format 

The  SP  production  format  provides  a  set  of  mechanisms  that  allow  more  concise  definitions,  and  automatic 
opumizauon  of  Soar  productions.  SP  is  a  preprocessor,  so  ( 1 )  it  does  not  fundamentally  change  what  can  and 
cannot  be  represented  in  OpsS  productions,  and  (2)  there  is  no  problem  with  mixing  together  traditional 
productions  (in  OpsS  format)  and  SP  productions. 

SP  provides  the  ability  to  match  a  context  in  either  the  traditional  way  or  by  a  single  SP  condition.  A 
context  such  as 

(goaf -context- info  ^identifier  <g>  tattribute  problem-space  Tvalue  <P>) 
(goal-context-info  Tidentifier  <g>  Tattribute  state  tvalue  <s>) 

can  be  given  as  is  or  shortened  to 

(goal-context  <g>  tproblem-space  <p>  tstate  <s>) 

SP  prov  ides  the  ability  to  specify  the  information  about  an  object  as  either  a  set  of  separate  conditions  or  as 

a  single  condition.  A  set  of  augmentations  about  an  object  such  as 

(state-info  tidentifier  <s>  tattribute  color 
tvalue  {<<  red  green  >>  <c>}) 

(state-info  tidentifier  <s>  tattribute  depth  tvalue  >  10) 

-(state-info  tidentifier  <s>  tattribute  weight  tvalue  <>  30) 

(state-info  tidentifier  <s>  tattribute  leg  tvalue  <legl>) 

(state-info  tidentifier  <s>  tattribute  leg  tvalue  <leg2>) 

(state-info  tidentifier  <s>  tattribute  name) 

(state-info  tidentifier  <s>  tattribute  <<  height  width  >> 
tvalue  small) 

can  be  given  as  is  or  shortened  to 

(state  <s>  tcolor  {<<  red  green  >>  <c>>  tdepth  >  10  -tweight  <>  30 
tleg  < 1  eg  1 >  <leg2>  tname  t<<  height  width  >>  small) 

Pour  aspects  are  of  note.  (1)  It  is  possible  to  mix  the  two  representations  within  the  same  production.  (2) 

Whereas  the  final  OpsS  production  can  not  have  variable  or  disjunctive  attributes,  both  are  possible  for 

attributes  in  SP.  since  each  augmentation  is  a  separate  working-memory  element  where  the  SP  attribute  is 

actually  a  value  in  the  OpsS  representation.  (3)  Negations  usually  appear  in  front  of  the  attribute,  but  can 

appear  in  front  of  the  whole  object  if  there  is  only  one  attribute  in  the  object.  (4)  If  there  are  multiple  values 

for  an  attribute,  a  separate  working-memory  element  is  created  for  each  value,  giving  a  simple  set  notauon. 


16 


SOAR  USER  S  MANUAL 


If  the  first  symbol  after  the  class  name  is  not  t,  then  the  condition  is  assumed  to  be  in  SP  format.  If  the  first 
symbol  is  a  t.  then  it  is  assumed  that  it  is  in  Ops5  format.  Preferences  are  always  in  Ops5  format,  but  the 

tobject  is  optional  if  the  object  identifier  directly  follows  the  class:  so 

(goal-context-info  tidentifier  <g>  tattribute  impasse  tvalue  <a>) 
(preference  tobject  <s>  trole  state  tvalue  acceptable  tgoal  <g>) 

can  be  shortened  to 

(goal  <g>  timpasse  <d>) 

(preference  <s>  trole  state  tvalue  acceptable  tgoal  <g>) 

The  same  format  can  be  used  for  both  conditions  and  actions.  In  the  actions,  the  placement  of  a  make  at  the 
front  of  the  object  (of  either  format)  is  optional.  There  is  a  global  list  (in  variable  *ops5-actions*)  which  is 
used  to  determine  whether  an  action  is  a  primitive  action  or  a  make. 

The  same  format  can  also  be  used  for  makes  at  the  top-level  of  LISP  that  initialize  working  memory.  For 
example 

(make  space-info  tidentifier  p  tattribute  operator  tvalue  opl) 

(make  space-info  tidentifier  p  tattribute  operator  tvalue  op2) 

can  be  given  as 

(smake  space  p  toperator  opl  toperator  op2) 

SP  provides  automatic  condition  ordering  to  yield  more  efficient  productions.  The  following  two 

productions  show  a  single  production  in  its  SP  form  and  its  ordered  P  ( Ops5)  form. 

(sp  eight*create-new-state 

(gc  <g>  tproblem-space  <p>  tstate  <s>  toperator  <o>) 

(problem-space  <p>  tname  eight-puzzle) 

(state  <s>  tblank-binding  <bl>  tbinding  <b2>) 

(operator  <o>  tcell  <c2>) 

(binding  <b2>  tcell  <c2>  ttile  <t2>) 

(binding  <bl>  tcell  <cl>  ttile  <tl>) 

--> 

(preference  <s2>  trole  state  tvalue  acceptable 

tgoal  <g>  tproblem-space  <p>  tstate  <s>  toperator  <o>) 

(state  <s2>  tswapped  <bl>  <b2>  tbinding  <b3>  <b4> 
tblank-binding  <b4>) 

(binding  <b3>  ttile  <t2>  tcell  <cl>) 

(binding  <b4>  ttile  <tl>  tcell  <c2>)) 
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(p  e ight*create-new-state 

(goal -context- info  ^identifier  <g>  ^attribute  problem-space 
tvalue  <p>) 

(space-info  Tidentifier  <p>  tattribute  name  tvalue  eight-puzzle) 
(goal -context- info  tidentifier  <g>  tattribute  state  tvalue  <s>) 
(goal -context-info  tidentifier  <g>  tattribute  operator  tvalue  <o>) 
(state-info  tidentifier  <s>  tattribute  blank-binding  tvalue  <bl>) 

( b i nd ing - i nf o  tidentifier  <bl>  tattribute  cell  tvalue  <cl>) 
(op-info  tidentifier  <o>  tattribute  cell  tvalue  <c2>) 

(state-info  tidentifier  <s>  tattribute  binding  tvalue  <b2>) 

( b i nd i ng- i nf o  tidentifier  <b2>  tattribute  cell  tvalue  <c2>) 

( b i nd ing - i n f o  tidentifier  <bl>  tattribute  tile  tvalue  <tl>) 

(binding- info  tidentifier  <b2>  tattribute  tile  tvalue  <t2>) 

--> 

(make  preference  tobject  <s2>  trole  state  tvalue  acceptable 
tgoal  <g>  tproblem-space  <p>  tstate  <s>  toperator  <o>) 

(make  state-info  tidentifier  <s2>  tattribute  swapped  tvalue  <bl>) 

(make  state-info  tidentifier  <s2>  tattribute  swapped  tvalue  <b2>) 

(make  state-info  tidentifier  <s2>  tattribute  binding  tvalue  <b3>) 

(make  state-info  tidentifier  <s2>  tattribute  binding  tvalue  <b4>) 

(make  state-info  tidentifier  <$2>  tattribute  blank-binding 
tvalue  <b4>) 

(make  binding-info  tidentifier  <b3>  tattribute  tile  tvalue  <t2>) 

(make  binding-info  tidentifier  <b3>  tattribute  cell  tvalue  <cl>) 

(make  binding-info  tidentifier  <b4>  tattribute  tile  tvalue  <tl>) 

(make  binding-info  tidentifier  <b4>  tattribute  cell  tvalue  <c2>)) 


In  addition  to  ordering  conditions.  SP  also  modifies  a  variable  in  the  role  of  a  goal-context-info  if  that 
variable  is  not  used  in  any  other  conditions.  The  modification  is  to  replace  the  variable,  say  <v>  with  {  <> 
undecided  <v>  }.  This  prevents  the  condition  from  matching  if  the  role  has  value  undecided. 


3.4.  Conjunctive  Negations 

The  distributed  representation  of  objects  as  multiple  working- memory  elements  makes  it  difficult  to  test  for 
the  absence  of  an  object  with  a  set  of  specific  features.  For  example,  if  the  user  wants  to  test  if  there  is  not  an 
object  in  working  memory  that  has  blue  toes  and  a  blue  nose,  the  following  conditions  would  not  make  the 
right  test. 

(sp  notreal lycol d 

context  tests  and  other  conditions 
-(state  <y>  ttoes  blue  tnose  blue) 

--> 

•  •) 

Assuming  that  <y>  is  unconstrained  by  the  other  conditions  of  the  production,  these  conditions  would  be 
satisfied  only  if  there  are  no  objects  that  have  blue  toes  and  no  objects  that  have  a  blue  nose,  while  the  desired 
behavior  is  to  have  them  be  satisfied  only  if  there  are  no  objects  that  have  both  blue  toes  and  a  blue  nose. 

One  solution  to  this  problem  requires  using  three  productions.  Production  pi  tests  for  the  co-occurrence  ot 
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positive  instances  of  the  negated  conditions  and  produces  a  single  working-memory  element  that  encodes  the 
fact  that  both  exist.  Production  p2  tests  for  the  context  when  the  original  production  would  fire  except  for  the 
negative  conditions  and  produces  a  unique  symbol.  Finally,  production  p3  tests  for  the  absence  of  the 

encoded  working-memory  element  produced  by  p  l  and  for  the  presence  of  the  one  generated  by  p2. 

(sp  pi 

context  tests  and  other  conditions 
(state  <y>  ttoes  blue  tnose  blue) 

--> 

(state  <y>  ttoesandnose  blue)) 

(sp  p2 

context  tests  and  other  conditions 
--> 

(state  <y>  tspecialattribute  value)) 

(sp  p3 

(state  <y>  tspecialattribute  value) 

-(state  <y>  ttoesandnose  blue) 

--> 

•  ••) 

A  simpler  and  more  correct  solution  to  this  problem  awaits  a  revised  implementation  of  the  OpsS  matcher 
used  in  Soar. 
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4.  Decision  Procedure 

The  purpose  of  the  decision  procedure  is  to  make  a  change  to  the  goal-context-stack  based  on  the 
preferences  in  working  memory.  The  change  is  either  the  replacement  of  the  current  value  of  one  role  of  an 
existing  context,  or  the  creation  of  a  new  context  because  of  an  impasse. 

The  decision  procedure  processes  the  goal-context-stack  from  oldest  goal  to  newest  goal  (ie..  from  the 
highest  supergoal  to  the  lowest  subgoal).  Kach  role  of  a  context  is  considered,  starting  with  the  problem-space 
and  continuing  through  the  state  and  operator  in  order.  For  a  given  slot,  all  preferences  relevant  to  that  slot 
are  collected.  A  preference  is  relevant  to  a  slot  if  all  of  its  non-nil  context  fields  (goal,  problem -space,  state 
and  operator)  have  the  same  identifiers  as  the  corresponding  roles  in  the  context  and  the  role  of  the 
preference  is  the  same  as  the  role  of  the  slot.  Lsing  these  preferences,  the  different  objects  competing  for  a 
slot  are  compared.  Ihe  decision  procedure  computes  a  final-choice  for  a  slot  according  to  the  semantics  of 
acceptability,  rejection  and  the  desirability  ordering.  1  he  semantics  of  these  concepts  is  given  in  Figure  4-1. 

To  determine  the  final-choice,  the  set  of  considered-choices  is  first  determined.  I  hese  arc  objects  that  are 
acceptable  (there  are  relevant  acceptable-preferences  for  them)  and  are  not  rejected  (there  are  no  relevant 
reject-preferences  for  them).  Consider  applying  the  decision  procedure  to  the  operator  slot  given  the  context 
and  preferences  in  Figure  4-2.  This  example  includes  many  preferences  which  may  not  arise  in  the  normal 
course  of  problem  solving,  but  they  help  exemplify  the  details  of  the  decision  process. 

Ihe  objects  with  relevant  acceptable-preferences  are  oOOOl,  o0002,  o0004.  These  acceptable-preferences 
differ  in  which  fields  they  specify,  but  all  of  the  specified  fields  appear  in  the  context.  Object  o0003  has  an 
acceptable-preference,  but  it  is  not  relevant  to  the  current  context  since  it  requires  that  state  s0006  be  selected. 
Fvcn  though  there  is  a  best-preference  for  o0003  that  is  relevant,  it  is  not  a  considered-choice  because  there  is 
no  relevant  acceptable-preference.  Although  o0004  is  acceptable,  it  is  also  rejected,  so  the  set  of  considered- 
choices  is  only  oOOOl.  o0002.  From  this  set.  the  dominant,  maximal  choice  must  be  determined. 

Dominance  is  determined  by  the  best,  better,  indifference,  worst,  and  worse-preferences.  An  object 
dominates  another  if  it  is  better  than  the  other  (or  the  other  is  worse)  and  the  latter  object  is  not  also  better 
than  the  former  object  (which  is  possible  because  conflicts  are  possible).  A  best  object  dominates  all  other 
non -best  objects,  except  those  that  are  better  than  it  through  a  better-preference  or  worse-preference.  A  worst 
object  is  dominated  by  all  other  non-worst  objects,  except  those  that  it  is  better  than  through  a  better  or  worse 
preference.  Ihe  maximal-choices  are  those  that  are  not  dominated  by  any  other  objects.  Consider  our 
example  oOOOl  is  a  best  object,  but  o()002  is  better  than  oOOOl.  o0002  becomes  the  maximal-choice  because 
it  directlv  dominates  oOOOl  through  a  better-preference.  !r  o()002  were  not  better  than  oOOOl.  oOOOl  would  be 


20 


SOAR  LSl-R'S  VIAMAI 


P 


Primitive  predicates  and  functions  on  objects,  x,  y,  z.  ... 


current 

The 

object  that  currently 

occupies 

the  slot 

acceptable! x) 

X 

is  acceptable 

reject(x) 

X 

is  rejected 

(x  >  y) 

X 

is  better  than  y 

(*  <  y) 

X 

is  worse  than  y  (same 

as  y  >  x 

) 

(x  ~  y) 

X 

is  indifferent  to  y 

(x  »  y) 

X 

dominates  y  =  (x  >  y) 

and  -'(y 

>  *) 

Reference  anchors 

indif ferent( x)  =>  Vy  [ indifferent(y }  =»  ( x  -  y)] 

best(x)  =»  Vy  [best(y)  =»  (x  ~  y)]  A  [->best(y)  A  — > ( y  >  x)  =»  (x  >  y ) ] 
worst(x)  =  Vy  [worst(y)  =»  ( x  -  y)]  A  [-’worst(y)  A  ->(y  <  x)  =»  (x  <  y )  ] 

Basic  properties 

Desirability  (x  >  y)  is  transitive,  but  not  complete  or  antisymmetric 
Indifference  is  an  equivalence  relationship  and  substitutes  over  > 

(x  >  y)  and  (y  ~  z)  implies  (x  >  z) 

Indifference  does  not  substitute  in  acceptable,  reject,  best,  and  worst, 
acceptab 1 e( x )  and  (x  ~  y)  does  not  imply  acceptable(y) . 
reject(x)  and  (x  -  y)  does  not  imply  reject(y).  etc. 

Default  assumption 

All  preference  statements  that  are  not  explicitly  mentioned  and 

not  implied  by  transitivity  or  substitution  are  not  assumed  to  be  true 

Intermediate  definitions 

considered-choices  =  (xcobjects  |  acceptable(x)  A  -reject(x)} 
maximal(X)  =  {xeX  J  Vy  -'(y  >>  x)} 
maximal-choices  *  max imal ( cons idered-choices ) 
empty(X)  =  -’3xcX 

mutual  ly-indifferent(X)  <=»  Vx.ycX  (x  -  y) 

random(X)  =  choose  one  element  of  X  randomly 

select(X)  =  if  currenteX  then  current  else  user-select(X) 

Final  choice 

empty(maximal-choices)  A  -’reject(current)  =»  f inal -choice( current ) 
mutual ly-indifferent(maximal-choices)  A  -’empty(maximal-choices) 

=»  f inal  -choi ce( sel ect (max imal -cho ices ) ) 

Impasse 

empty(maximal -choices )  A  reject(current )  =>  re ject ion- impasse( ) 

-’mutual  ly-  ind  i  f  fe  rent  (max  imal -  cho  ices)  =»  impasse  ( max  imal  -  cho  ices ) 

Figure  4-1 :  The  semantics  of  preferences. 

the  maximal-choice.  If  there  were  neither  the  better-preference  nor  the  best-preference,  the  maximal-choice 
would  consist  of  both  objects. 


Once  the  maximal-choice  for  a  slot  is  computed,  the  decision  procedure  determines  whether  there  is  a  final 
choice  or  an  impasse  for  the  slot  using  the  ruics  at  the  bottom  of  Figure  4-1  these  rules  are  mutuallv 
exclusive  and  complete.  I  he  current  object  acts  as  a  default  so  that  a  given  slot  will  change  only  if  the  current 


[)(  CISIOS  PROCKJL  Ri:  ll 

(gc  gOOOl  tproblem-space  p0003  tstate  s0004  toperator  o0007) 

(preference  oOOOl  trole  operator  tvalue  acceptable 
tgoal  gOOOl  tproblem-space  p0003) 

(preference  oOOOl  trole  operator  tvalue  best 
tgoal  gOOOl  tproblem-space  p0003) 

(preference  o0002  trole  operator  tvalue  acceptable 

t goal  gOOOl  tproblem-space  p0003  tstate  s0004  toperator  o0007) 
(preference  o0002  trole  operator  tvalue  better  treference  oOOOl 

tgoal  gOOOl  tproblem-space  p0003  tstate  s0Q04  toperator  o0007) 

(preference  o0003  trole  operator  tvalue  acceptable 

tgoal  gOOOl  tproblem-space  p0003  tstate  s0006) 

(preference  o0003  trole  operator  tvalue  best 

tgoal  gOOOl  tproblem-space  pQQ03  tstate  s0Q04) 

(preference  o0004  trole  operator  tvalue  acceptable 
tproblem-space  p0003) 

(preference  o0004  trole  operator  tvalue  reject 

tgoal  gOOOl  tproblem-space  p0003  tstate  s0004 
toperator  undecided) 

Figure  4-2:  An  example  goal-context  with  preferences  for  operator  selection. 

object  is  displaced  by  another  object.  Whenever  there  is  no  maximal-choice  for  a  slot,  the  current  object  is 
maintained,  unless  the  current  object  is  rejected,  in  which  case  a  reiecnon  impasse  arises.  If  the  current  object 
is  one  of  the  maximal-choices  and  it  is  indifferent  to  the  other  maximal-choices  (or  it  is  the  only  maximal- 
choice),  then  the  current  object  is  maintained,  since  indifferent  signifies  that  either  object  is  appropriate.  If 
the  current  object  is  not  a  maximal-choice,  and  the  maximal-choices  are  mutually  indifferent,  the  current 
object  is  displaced  by  one  of  the  maximal-choices.  A  set  of  objects  arc  mutually  indifferent  if  all  pairs  in  that 
set  are  indifferent  Two  objects  are  indifferent  if  either  there  exists  a  binary  indifferent-preference,  there  is  a 
transitive  set  of  binary  indifferent-preferences  containing  both  of  them,  they  are  both  in  unary  indifferent- 
preferences.  they  are  both  in  best-preferences  or  they  are  both  in  worst-preferences.  In  the  current  example, 
there  is  only  a  single  maximal-choice.  o0002.  which  would  displace  o0007.  If  all  of  the  maximal-choices  are 
mutually  indifferent,  user-select  is  tested  to  determine  how  to  select  between  the  objects.  This  can  be  cither 
randomly,  deterministically,  or  by  the  user.  See  Section  10.3.7  for  more  details. 

If  the  current  object  is  to  be  displaced  by  the  maximal-choice,  and  there  is  not  a  single  object  (or  set  of 
indifferent  objects)  that  dominates,  then  either  a  nr  or  conflict  impasse  arises.  A  conflict  impasse  arises  if  the 


between  the  maximal-choice  obiccts.  a  no-chanee  impasses  arises  if  a  context  has  been  processed  and  none  of 


Che  slots  has  been  changed.  If  the  current  object  is  not  displaced,  or  if  a  pre-existing  impasse  still  exists,  the 
decision  procedure  then  prexesscs  the  next  slot,  either  in  the  current  context  or  the  next  lower  context  if  the 
operator  slot  was  just  processed.  If  a  new  impasse  is  encountered,  all  subgoals  are  terminated,  a  new  subgoal 
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is  created  and  the  elaboration  phase  of  the  next  decision  cycle  ensues.  (A  tie  or  conflict  impasse  is  considered 
to  be  equivalent  to  a  prev  ious  tie  or  conflict  impasse  if  the  objects  involved  in  the  new  impasse  arc  a  subset  of 
those  in  the  existing  impasse.) 

With  appropriate  preferences  from  the  elaboration  phase,  it  is  possible  for  a  single  object  to  result  from  the 
decision  procedure,  i.e..  the  maximal-choice  set  contains  exactly  one  object  or  a  set  of  indifferent  object  from 
which  a  single  object  is  chosen  as  describe  in  Section  10.3.7.  When  there  is  a  single  object,  the  change  is 
installed,  all  unconsidered  slots  of  the  current  context  set  to  undefined,  all  unconsidcred  contexts  terminated, 
and  the  elaboration  phase  of  the  next  decision  cycle  ensues. 
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5.  Subgoals 

All  subgoals  in  Soar  are  created  automatically  by  the  architecture  when  a  new  impasse  arises  in  the  decision 
procedure.  There  are  currently  four  types  of  impasses,  leading  to  four  types  of  subgoals. 

•  A  tie  impasse  arises  if  the  preferences  for  a  slot  do  not  distinguish  between  competing  objects. 

•  A  conflict  impasse  arises  if  at  least  two  objects  have  conflicting  preferences  (such  as  A  is  better 
than  B  and  B  is  better  than  A)  for  a  slot. 

•  A  no-change  impasse  arises  if  none  of  the  slots  change  value  during  the  decision  procedure. 

•  A  rejection  impasse  arises  if  all  objects  with  acceptable-preferences  for  a  role  also  have 
reject-preferences. 

The  first  two  impasses,  tie  and  conflict,  are  multi-choice  impasses,  because  more  than  one  object  remains 
following  the  decision  procedure.  The  last  two  impasses,  no-change  and  rejection  are  no-choice  impasses, 
because  there  are  no  objects  available  from  which  to  choose.  The  four  impasses  are  mutually  exclusive  and 
exhaustive. 

When  a  new  impasse  is  detected.  Soar  creates  a  gensymed  goal  symbol  and  an  associated  goal-context  which 
includes  the  problem  space,  state  and  operator  for  the  goal,  as  well  as  a  set  of  augmentations  that  help  define 
the  goal.  Below  are  the  nine  goal-context-info  augmentations  that  can  be  created. 

problem-space  This  contains  the  identifier  of  the  current  problem-space  for  the  goal:  undecided. 

state  This  contains  the  identifier  of  the  current  state  for  the  goal:  undecided. 

operator  This  contains  the  identifier  of  the  current  operator  for  the  goal:  undecided. 

impasse  This  contains  the  type  of  impasse:  tie.  conflict,  no-change,  rejection. 

choices  This  contains  either  multiple,  for  tie  and  conflict  impasses,  and  none,  for  no-change 

and  rejection  impasses. 

role  For  multi-choice  impasses  (tie  and  conflict),  this  contains  the  role  that  the  choices 

were  competing  for  (problem-space,  state,  operator).  For  no-change  impasses,  this 
contains  the  role  of  the  last  slot  that  is  not  undefined  (goal,  problem-space,  state, 
operator).  For  rejection  impasses,  this  contains  the  role  of  the  slot  just  above  the  slot 
where  the  rejecuon  occurred  (goal,  problem-space,  state).  Rejection  is  defined  in  this 
way  so  that  both  no-change  and  rejection  impasses  have  the  same  role  for  a  similar 
difficulty. 

item  If  the  impasse  has  multiple  choices,  each  acceptable  object  for  the  slot,  that  was  either 

tied  or  conflicted,  is  included  as  an  individual  item  augmentation. 
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supergoal  This  contains  the  identifier  of  the  supergoal. 

superoperator  This  contains  the  identifier  of  the  superoperator.  Ihis  is  necessary  for  the  subgoals 
that  arise  from  parallel  operators  so  that  each  subgoal  is  for  a  different  parallel 
superoperator  (see  Section  9.2). 

Here  is  an  example  of  a  goal-context  that  is  created  for  a  tie  between  three  operators: 

(gc  G0012  timpasse  tie  tchoices  multiple  trole  operator 
tsupergoal  G0003  tsuperoperator  undecided 

rproblem-space  undecided  tstate  undecided  toperator  undecided 
titem  00009  titem  00010  titem  00011) 


A  subgoal  terminates  when  its  impasse  is  eliminated  by  the  addition  of  preferences  that  change  the  results 
of  the  decision  procedure  for  a  supergoal.  Kor  example,  if  there  is  a  tie  subgoal  between  two  objects,  it  will 
automatically  terminate  when  a  new  preference  is  added  to  working  memory  that  rejects  one  of  the  choices, 
makes  one  a  best  choice,  makes  one  better  than  another,  makes  one  a  worst  choice,  or  makes  them  both 
indifferent.  If  there  is  a  tie  between  three  objects,  the  tie  will  be  broken  when  one  of  the  objects  (or  a  set  of 
indifferent  objects)  dominates  the  others.  So  the  subgoal  will  terminate  if  a  best-preference  is  created  for  one 
of  the  objects,  if  one  object  is  made  better  than  the  other  two.  and  so  on. 


When  a  subgoal  is  terminated,  many  of  the  working-memory  elements  that  were  created  in  the  subgoal  are 
automatically  removed  from  working  memory.  All  working-memory  elements  created  in  the  subgoal  (and 
those  created  in  its  subgoals)  that  are  linked,  directly  or  indirectly,  to  any  supergoal,  will  be  retained.  The 
determination  of  which  working-memory  elements  to  remove  is  done  by  a  mark-and-sweep  garbage- 
collection  scheme.  When  a  subgoal  terminates,  all  working-memory  elements  that  were  created  in  the 
subgoal  (and  its  subgoals)  are  collected  together.  All  augmentations  (but  not  preferences)  whose  identifier 
appears  in  one  of  the  working-memory  elements  that  existed  prior  to  the  subgoal  are  saved.  This  recurs  by 
saving  those  elements  whose  identifiers  appear  in  a  saved  element  until  no  additional  elements  arc  saved. 
Preferences  are  saved  if  their  context  objects  (identifiers  in  the  goal,  problem  space,  state,  and  operator  fields) 
are  nil  or  existed  before  the  subgoal  was  created.  All  working-memory  elements  that  were  created  in  the 
subgoal,  but  not  saved,  are  removed  from  working  memory.  All  saved  elements  are  considered  to  have  been 
created  in  the  supergoal  for  all  future  garbage  collections. 
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6.  Default  Search  Control 

[  This  chapter  describes  the  default  knowledge  in  Soar.  This  is  encoded  in  a  set  of  51  productions  that  are 

!  always  loaded  in  with  a  task.  These  productions  are  listed  in  Appendix  1.  The  majority  of  this  knowledge 

provides  default  responses  to  the  impasses  that  can  arise  during  problem  solving.  Soar  provides  default 
'  processing  for  every  subgoal  that  can  arise.  This  chapter  starts  with  default  knowledge  that  is  applicable  in  all 

i  subgoals.  T  his  is  followed  by  the  default  responses  to  the  different  impasses,  which  includes  the  selection 

problem  space,  evaluation  subgoals  and  operator  subgoaling. 

6.1.  Common  Search-Control  Productions 

'  •  default*make-all-operators-acceptable:  If  the  current  problem  space  is  augmented  with  an 

operator  (the  operator  is  the  value  of  a  toperator  attribute),  make  an  acceptable-preference  for  the 
operator  with  the  current  problem  space  in  the  problem  space  field,  and  nil  in  all  other  context 
fields. 

•  default*no-operator-retry:  If  there  is  an  acceptable-preference  for  the  current  state,  create  a 
reject-preference  for  the  operator  in  the  toperator  field  using  the  context  fields  for  goal,  problem 
space  and  state  from  the  acceptable-preference  for  the  current  state  (assuming  that  the  operator  is 
not  undecided  or  nil). 

•  default*backup-if-failed-state:  If  there  is  a  reject-preference  for  the  current  state,  make  an 
acceptable-preference  for  the  state  that  was  used  to  create  it. 

6.2.  Default  Knowledge  for  Impasses 

6.2.1.  Multi-choice  impasses 

If  a  subgoal  is  created  for  a  tie  or  conflict  impasse,  an  acceptable-preference  and  a  worst-preference  are 
created  for  the  selection  problem  space.  The  selection  problem  space  is  used  by  default  for  all  tie  and  conflict 
impasses.  See  Section  6.3  for  more  information.  As  backup  to  the  selection  problem  space,  there  are 
additional  productions  that  apply  if  a  multi-choice  impasse  is  followed  by  a  no-choice  impasse  for  the  goal, 
which  would  arise  if  the  selection  space  was  rejected.  If  the  impasse  was  a  tie.  worst-preferences  are  created 
for  the  items  that  tied  by  default*problem-space-tie.  default*state-tie,  and  default*operator-tie.  If  the  impasse 
was  a  conflict,  reject-preferences  are  created  for  the  items  that  conflicted  by  default*problem-space-conflict. 
default*state-conflict,  and  default*operator-conflict. 
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6.2.2.  No-choice  impasses  •  goal 

The  impasses  where  tchoices  is  none  and  trole  is  goal  arc  used  as  a  signal  that  no  progress  was  possible  for 
the  next  higher  impasse.  That  is.  only  when  there  is  no  knowledge  about  how  to  eliminate  an  impasse  (no 
acceptable  problem  spaces  are  suggested,  or  they  arc  all  rejected)  do  these  impasses  arise.  Such  an  impasse 
leads  to  the  rejection  of  the  last  defined  object  in  the  super-context.  If  there  is  a  no-choice  impasse  for  the  top 
goal.  defau!t*goal-no-choices  halts  Soar. 

6.2.3.  No-choice  impasses  •  problem  space,  state  and  operator 

If  no  problem  space  is  selected  to  handle  one  of  these  subgoals  (signalled  by  the  creation  of  a  no-choice 
impasse  for  the  goal),  this  implies  that  there  is  no  knowledge  available  to  resolve  the  no-choice  impasse.  The 
default  response  is  to  reject  the  lowest  object  in  the  goal-context  that  is  not  undecided.  This  has  the  effect  of 
allowing  another  choice  to  replace  the  rejected  choice  so  that  another  path  can  be  attempted,  or  of  further 
rejecting  a  higher-choice  if  the  rejected  object  was  the  only  candidate  for  its  slot.  This  is  implemented  by 
productions  default*problem-space-no-choices.  default*state-no-choices.  and  default*operator-no-choices. 

6.2.4.  No-change  impasses  -  operator 

If  a  no-change  subgoal  is  created  for  the  operator  role,  there  arc  three  possible  reasons:  ( l)  the  conditions 
of  the  operator  were  not  satisfied;  (2)  the  operator  is  incompletely  specified  (needs  to  be  instantiated);  (3)  the 
operator  is  too  complex  to  be  performed  by  productions  and  must  be  implemented  in  a  subgoal  in  its  own 
problem  space.  For  the  first  option,  the  appropriate  response  is  to  use  the  same  problem  space  and  search  for 
a  state  where  the  operator  will  apply  (operator  subgoaling).  For  the  others,  task-specific  problem  spaces  must 
be  available  to  perform  the  necessary  computations.  Because  task-specific  knowledge  is  required  for  the  last 
two  cases,  we  assume  that  the  first  is  the  default  action;  that  is.  an  acceptable-preference  and  a  worst- 
preference  are  created  for  the  super-problem-space.  These  will  be  overridden  by  any  acceptable-preferences 
for  other  problem  spaces.  See  Section  6.5  for  more  details.  If  operator  subgoaling  fails,  and  all  problem 
spaces  for  the  subgoal  are  rejected.  default*operator-no-choices  will  then  reject  the  operator  that  led  to  the 
impasse. 

6.3.  Selection  Problem  Space 

Whenever  a  multi-choice  impasse  is  encountered,  an  acceptable-preference  is  made  for  the  %e!eau>n 
problem  space.  There  is  also  a  worst-preference  created  for  it.  so  that  anv  user  provided  problem  space  will 
be  selected  in  ns  place.  Both  of  these  are  created  by  select*selection-space.  The  states  ot  the  selection 
problem  space  may  have  evaluations  of  the  tieing  objects  as  augmentations.  An  initial,  empty  state  is  aeated 
by  select*create-state.  There  is  one  operator  provided  with  the  selection  space:  evaluate-object 


DIXAL'LT  SEARCH  CONTROL 


27 


6.3.1.  The  evaluate-object  operator 

Evaluateobject  is  meant  to  create  evaluations  for  the  tieing  or  conflicting  objects  so  that  preferences  can  be 
created  by  comparing  the  evaluations  of  the  different  objects.  Production  eval*seleet-ev aluate  creates  an 
operator  instance  for  each  object  that  is  an  titem  augmentation  of  the  goal.  These  operators  are  named 
evaluate-object.  When  they  are  created,  acceptable  and  indifferent-preferences  arc  also  created  tor  them,  so 
that  there  will  be  no  tie  between  them  (however,  by  using  the  user-select  function,  the  user  can  choose  which 
evaluate-object  operator  to  apply  first).  The  user  can  also  have  evaluate-object  operators  applied  in  parallel 
by  loading  in  production  eval*parallcl-evaluatc  which  resides  in  default.soar.  but  is  currently  commented  out. 
See  Section  9.2  for  more  on  parallelism. 

Each  evaluate-object  operator  is  created  w  ith  the  follow  ing  three  augmentations. 

•  tstate:  the  current  state  of  the  selection  subgoal. 

•  tname:  evaluate-object. 

•  tobject:  the  identifier  of  the  object  to  be  evaluated. 

Once  an  evaluate-object  operator  is  selected  as  the  current  operator,  it  is  augmented  with  further  information. 
This  information  is  only  necessary  if  the  operator  is  going  to  be  applied,  therefore  it  is  more  efficient  to 
generate  it  only  if  the  operator  is  selected. 

•  trole:  the  role  in  the  context  for  which  the  object  is  tied  or  conflicted  (problem-space,  state,  or 
operator). 

•  revaluation,  the  identifier  of  an  newly  created  object  that  will  hold  the  evaluation.  Ihis  is 
described  in  more  detail  in  Secuon  6.3.2. 

•  tdesired:  the  desired  of  the  supergoal  (the  one  in  which  the  impasse  arose).  The  desired  of  a  goal 
contains  the  identifier  of  an  object  that  describes  the  desired  state  of  the  goal. 

•  tsupergoal:  the  identifier  of  the  supergoal. 

•  tsuperproblem-space  the  identifier  of  the  problem  space  selected  in  the  supergoal. 

•  rsuperstate  the  identifier  of  the  state  selected  in  the  supergoal. 

I  hese  .luement.i'inns  provide  easv  access  to  information  required  for  compuung  evaluations. 

6.3.2  Evaluation  objects 

mentioned  above  i  new  .h|ect  of  class  evaluation  is  created  when  an  evaluate-object  operator  is 
selected.  It  has  the  tolliming  luerncnt  itions 

•  v  object  the  identifier  ot  the  tied  or  conflicted  object  to  be  evaluated. 
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•  tstate:  the  current  state  of  the  multi-choice  subgoal. 

•  tdesired:  the  desired  of  the  supergoal  (the  one  in  which  the  impasse  arose).  The  desired  of  a  goal 
contains  the  identifier  of  an  object  that  describes  the  desired  state  of  the  goal. 

•  toperator:  the  identifier  of  the  evaluatc-object  operator  of  which  this  evaluation  is  an 
augmentation. 

The  evaluation  object  is  used  to  hold  the  evaluation  computed  by  the  operator,  f  or  two-player  games  (such 
as  Tic-lac-Toc)  the  evaluation  can  also  hold  the  side  of  the  player  to  move.  See  Section  6.3.7  for  more 
information. 

Currently,  there  is  default  knowledge  for  two  types  of  evaluations:  numeric  and  symbolic.  I  hey  arc 
distinguished  by  the  augmentation  that  is  added  to  the  evaluation  object  when  they  are  computed.  Numeric 
evaluations,  such  as  a  number  between  1  and  10.  arc  added  as  augmentations  of  the  tnumeric-value  attribute. 

For  example,  if  an  ev  aluation  is  computed  to  be  10.  it  might  appear  in  working  memory  as: 

(evaluation  £0004  tobject  00044  tstate  S0034  tdesired  E3330 
toperator  05555  tnumeric-value  10) 

Symbolic  evaluations,  such  as  success,  failure,  win,  k»se.  or  draw  arc  added  as  augmentations  of  the 

tsymbolic-value  attribute.  For  example,  the  same  evaluation  as  above  with  success  would  be: 

(evaluation  E0004  tobject  00044  tstate  S0034  tdesired  E3330 
toperator  05555  tsymbol ic-value  success) 

6.3.3.  Applying  the  evaluate-object  operator 

A  specific  instance  of  evaluate-object  can.  but  often  wilt  not  have  any  productions  that  directly  implement 
it.  t  he  production  eval*apply-evaluate  will  apply,  but  only  to  fully  instantiate  the  operator.  Fherefore.  an 
operator  no-change  impasse  will  arise;  and  a  subgoal  will  be  created  to  compute  the  evaluation.  This  is 
discussed  in  Section  6.4.  Once  subgoals  have  been  used  to  compute  evaluations,  chunks  that  have  been  built 
from  the  subgoals  can  directly  compute  the  evaluations.  Users  arc  free  to  create  their  own  productions  that 
directly  compute  evaluations. 

6.3.4.  Terminating  the  evaluate-object  operator 

Hvaluate-objeci  is  terminated  by  production  eval*reject-evaluute-finished.  which  detects  if  the  curren' 
evaluate-object  operator  is  augmented  with  an  evaluation  object  that  has  an  evaluation  with  either  a 
tnumeric-value  or  tsvmbolic-value  augmentation.  In  either  case,  a  reject-preference  is  created  tor  the 
evaluatc-object  operator.  If  the  evaluation  does  not  lead  to  the  termination  of  the  multi-choice  subgoal,  the 
rcjcct-prcfcrcncc  will  lead  to  the  selection  of  another  evaluatc-object  operator  or  the  failure  of  the  problem 
space. 
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6.3.5.  Comparing  numeric  evaluations 

Once  evaluations  are  created  for  tieing  objects.  they  can  be  compared  and  preferences  can  be  created  that 
break  the  impasse.  For  numeric  evaluations  (evaluations  with  a  tnumeric-value  augmentation)  users  can  write 
their  own  productions  to  compare  the  evaluations.  If  the  objects  being  evaluated  are  operators  (almost  always 
the  case)  Soar  provides  some  help.  If  the  object  in  the  tdesired  augmentation  of  the  supergoal  (which  is 
usually  the  desired  state)  is  of  class  evaluation  and  is  augmented  with  tbetter  higher  or  tbetter  lower 
(depending  on  whether  a  higher  or  lower  evaluation  is  better),  then  productions  eval*prefer-highcr-evaluation 
and  eval*prcfeMower-evaluation  detect  the  appropriate  tbetter  augmentations  and  create  preferences  when 
one  evaluation  is  numerically  greater  than  another.  Production  eval*equal-eval-indiffcrent-preference  creates 
indifferent-preferences  for  objects  that  have  evaluations  that  are  numerically  equal,  independent  of  a  tbetter 
augmentation. 

6.3.6.  Comparing  symbolic  evaluations 

If  an  evaluation  has  tsymbolic-value  success,  production  eval*success-becomes-best  creates  a  best- 
preference  for  the  object  that  was  being  evaluated.  Phis  should  break  the  tie  and  allow  problem  solving  to 
continue.  An  evaluation  should  be  marked  with  tsymbolic-value  success  only  if  it  is  known  to  be  on  the  path 
to  the  goal,  either  because  the  goal  was  reached  when  evaluating  the  object  or  because  an  intermediate  state 
was  achieved  that  was  known  from  prior  experience  (i.e.,  chunks)  to  be  on  the  path  to  the  goal.  We  will  see  in 
Section  6.4  that  Soar  has  productions  that  will  propagate  success  up  a  subgoal  hierarchy  when  n  is 
appropriate. 

If  an  evaluation  has  tsymbolic-value  failure,  production  eval*fai!ure-becomes-worst  creates  a  worst- 
preference  for  the  object  that  was  being  evaluated.  Iliis  may  or  may  not  break  the  tie  and  allow  problem 
solving  to  continue.  An  evaluation  should  be  marked  with  tsymbolic-value  failure  only  if  it  is  known  not  to 
be  on  a  path  to  the  goal. 

6.3.7.  Evaluations  for  two-player  games 

For  two-player  games,  there  are  additional  productions  that  process  symbolic  values  win.  lose,  and  draw. 
These  depend  on  the  state  having  two  augmentations:  tside  and  toside.  t  he  value  of  the  side  augmentation 
should  be  a  symbol,  number  or  identifier  that  represents  the  player  that  is  to  move  next  in  the  current  state. 

I  he  value  of  the  toside  (other  side)  augmentation  should  represent  the  player  that  just  moved.  The  values  of 
win.  lose,  or  draw  are  in  relation  to  the  player  that  just  moved,  that  is.  the  one  that  is  in  toside.  Therefore, 
when  an  evaluation  object  is  augmented  with  a  symbolic  value  of  win  lose,  or  draw,  the  evaluation  must  also 
be  augmented  with  tside  which  contains  the  value  from  toside  in  the  state.  If  the  state  is  augmented  with 
twin,  tlosc.  or  tdraw.  as  described  in  Section  6  4.3.  then  production  eval*move-side-to-eval  will  copy  the  side 
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correctly.  Once  an  evaluation  of  win.  lose,  or  draw  has  been  created,  it  is  translated  into  a  preference  by 
eval*winmng-values.  eval*H inning- values!  eval*losing-values.  oal*losing-values2  and  eval*draw-values.  A 

win  for  the  side  on  move  or  a  lose  for  the  side  that  just  moved  becomes  a  best-preference,  a  lose  for  the  side 
on  move  or  a  win  for  the  side  that  just  moved  becomes  a  worst-preference,  and  a  draw  becomes  an  indifferent- 
preference. 

6.4.  Evaluation  Subgoal 

If  an  evaluate-object  operator  has  been  selected  and  no  productions  create  evaluation  values  for  it.  an 
operator  no-change  impasse  will  arise  and  a  subgoal  will  be  created.  In  this  subgoal,  the  context  that  led  to 
the  tie  will  be  re-established  and  the  tieing  object  that  is  an  augmentation  of  the  evaluate-object  operator  will 
be  selected.  This  allows  the  problem  solv  mg  to  continue  so  that  an  evaluation  of  the  success  of  that  object  can 
be  made.  Kor  different  types  of  objects,  different  amounts  of  the  context  have  to  be  re-established.  The 
production  eval*select-role-prohlem-space  is  used  for  tied  problem  spaces,  and  it  augments  the  current  goal 
with  the  old  desired  and  makes  an  acceptable-preference  for  the  problem  space  attached  to  the  evaluate- 
object  operator  in  the  object  augmentation.  The  production  eval*select-role-state  is  used  for  tied  states.  It 
augments  the  goal  with  the  desired-state  description  (tdesired).  creates  an  acceptable-preference  for  the 
super-super-problem-space  (which  is  in  the  super-problem-space  augmentation  of  the  evaluate-object 
operator)  and  creates  acceptable  and  best-preferences  for  the  state  in  the  object  augmentation  of  the  evaluate- 
object  operator.  Similarly.  eval*select-role-operator  re-establishes  the  old  desired-state,  problem  space  and 
state  and  then  creates  an  acceptable-preferences  for  the  operator  in  the  object  augmentation  of  the  evaluate- 
object  operator.  The  production  eval*reject-non-slot-operator  rejects  all  of  the  other  operators  that  compete 
for  the  operator  slot.  This  is  necessary  because  new  operator  instantiations  may  be  created  in  the  subgoal  that 
will  compete  (and  possibly  receive  best-preferences)  for  the  operator  slot.  Following  this,  problem  solving  is 
expected  to  continue  until  an  evaluation  is  produced  (of  course,  there  may  be  many  subgoals  along  the  way  to 
an  evaluation).  Once  the  evaluation  is  produced,  the  evaluate-object  operator  is  rejected  as  described  above. 

6.4. 1 .  Default  evaluations 

In  four  cases,  the  evaluations  can  be  determined  based  on  preferences  created  in  the  subgoals  and  not  on 
any  features  of  the  states  or  operators. 

1.  If  an  operator  is  being  evaluated  and  that  operator  is  rejected  for  the  initial  state  of  the  evaluation 
subgoal,  production  eval*failure-if-reject-evjling-operator  will  augment  the  evaluation  with 

tsymbolic-value  failure. 

2.  If  an  operator  is  being  evaluated  and  the  state  that  is  created  from  applying  that  operator  to  the 
initial  state  of  the  evaluation  subgoal  is  rejected,  production  eval*failurc-if- reject-state  will 
augment  the  evaluation  with  tsymbolic-value  failure. 
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3.  If  an  object  is  betng  evaluated  below  a  selection  problem  space,  there  can  be  a  tie  impasse  with  a 
second  selection  problem  space  in  the  search  for  an  evaluation.  If  during  the  problem  solving  in 
the  second  selection  problem  space  an  evaluation  of  tsymbolic-value  success  is  produced  relative 
to  the  same  desired  state  as  the  original  object.  cval*pass-back-success  will  assign  an  evaluation  of 
tsymbolic-value  success  to  that  original  object. 

4.  If  an  operator  is  being  evaluated  below  a  selection  problem  space  for  a  two-player  game,  there  can 
be  a  tic  impasse  with  a  second  selection  problem  space  in  the  search  for  an  evaluation.  If  during 
the  problem  solv  ing  in  the  second  selection  problem  space  an  evaluation  of  tsymbolic-value  win  is 
produced  for  the  same  side  as  the  original  operator.  cval*pass-back-win  and  eval*pass-hack-win2 
will  augment  us  evaluation  with  tsymbolic-value  win. 

6.4.2.  Computing  numeric  evaluations 

Numcnc  evaluations  can  be  computed  by  a  single  production,  a  set  of  productions,  or  a  subgoal.  All  of 
these  methods  must  create  the  right  augmentation  of  the  correct  object  so  that  the  rest  of  the  productions  can 
use  it  to  terminate  the  evaluatc-objcct  operator  and  create  preferences  for  the  tieing  objects  by  comparing 
evaluations.  The  correct  action  is  to  augment  the  evaluation  object  (which  is  the  value  of  the  revaluation 
augmentation  of  the  evaluatc-objcct  operator)  with  tnumcric-value  number.  Hor  example,  your  production 
would  contain  at  least  the  following: 

( sp  your-production-namc 

(gc  <g>  tproblem-space  <p>  rstate  {  <>  <$s>  <s>  } 
rsuperoperator  <so>) 

(problem-space  <p>  tname  your-task-problcm-space-name) 

(operator  <so>  tname  evaluate-object  revaluation  <e> 

^superstate  <ss>) 
conditions  that  match  features  of  state  <s> 

(evaluation  <e>  tnumeric-value  your-evaluation ) ) 

Numeric  evaluations  are  useful  when  features  of  a  state  correspond  to  the  distance  from  the  state  to  the  goal 
and  can  be  mapped  onto  either  the  integer  or  the  real  numbers.  The  value  computed  for  each  state  can  then 
be  compared  to  the  value  computed  for  another  state  and  a  preference  can  be  created  based  on  the  ordering 
of  the  numeric  values.  Complex  combinations  of  numbers  for  a  numeric  evaluation  of  a  state  is  possible  using 
the  compute  action.  For  example,  your-evaluation  could  be  the  addition  of  two  other  numbers:  (compute 
<numl>  +  <num2> ).  See  Section  3.2  fora  further  description  of  compute. 

6.4.3.  Computing  symbolic  evaluations 

Hie  same  approach  that  was  used  in  numcnc  evaluations  can  also  be  used  in  symbolic  evaluations,  except 
that  the  correct  augmentation  for  the  evaluation  object  is  tsymbolic-value  instead  of  tnumeric-valuc.  \ 
simpler  approach  is  also  available  so  that  the  user  docs  not  have  to  even  deal  with  evaluation  objects.  Instead 
of  augmenting  the  evaluation  object,  the  user  can  augment  the  current  state  of  the  subgoal  with  one  of  the 
following  five  attributes:  tsuccess.  tfailure.  twin,  tdraw.  tiose.  The  value  of  these  augmentations  must  be  the 
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t desired  augmentation  of  the  goal.  A  default  production  then  converts  those  state  augmentations  to  the 
corresponding  symbolic-value  augmentations  for  the  evaluation  object.  Kor  example,  use  a  production  like 
the  following: 

( sp  your-production-namc 

(gc  <g>  rproblem-space  <p>  tstate  <s>  rdesired  <desired>) 
conditions  that  detect  subgoal  success. 

--> 

(state  <s>  ^success  <desired>)) 

I  he  production  involved  in  the  conversion  is:  eval*statc-to-symbolic-evaluation. 

6.4.4.  Detecting  success  and  failure 

If  a  state  for  the  top  goal  in  Soar  is  marked  with  tsucccss.  twin,  or  tlose.  one  of  the  following  productions 
will  cause  Soar  to  halt:  eval*detect-succcss.  eval*detect-win.  eval*detcct-lose.  If  a  state  for  the  top  goal  in 
Soar  is  marked  with  tfailure.  it  will  be  rejected  by  eval*dctect-failure. 

6.5.  Operator  Subgoaling 

If  an  operator  has  been  selected  but  cannot  be  applied  to  the  current  state,  a  useful  strategy  is  to  create  a 
subgoal  to  find  a  state  where  the  operator  can  be  applied.  This  strategy  is  called  operator  subgoaling  (also 
precondition  satisfaction)  and  is  a  common  Al  technique  dating  back  to  GPS.  In  Soar,  operator  subgoaling  is 
appropriate  when  an  operator  has  been  selected  and  a  no-change  impasse  arises.  In  such  a  situation, 
acceptable  and  worst-preferences  are  created  for  the  supcr-problem-space  for  the  subgoal  by 
opsub*try-operator-subgoaling.  If  no  other  problem  spaces  are  suggested  for  the  goal,  the  problem  space  of 
the  supergoal  will  be  selected,  allowing  a  search  to  be  performed  in  the  same  problem  space  as  the  supcrgoal. 
but  with  a  new  goal  —  applying  the  currently  selected  operator.  The  presumption  is  that  the  selected  operator 
could  not  apply  to  the  current  state,  so  another  state  must  be  found.  The  default  productions  are  adequate  to 
implement  operator  subgoaling.  so  that  no  additional  productions  must  be  added  by  the  user. 

Once  the  supcr-problem-space  has  been  selected,  the  goal  is  named  operator-subgoal  and  augmented  with 
the  superoperator  as  its  tdesired  by  opsub*go-for-it.  This  establishes  a  convention  that  when  the  desired 
augmeniauon  of  a  goal  is  an  operator,  then  the  object  of  the  goal  is  to  achieve  a  state  in  which  the  operator 
can  be  applied.  Opsub*go-for-it  also  creates  an  acceptable-preference  for  the  superstate.  Once  the  superstate 
is  selected,  a  reject-preference  is  created  for  the  superoperator  with  the  initial  state  in  the  state  context  field, 
by  opsuh*rcject-opsub*opcrator.  since  it  is  known  that  it  will  not  apply  to  it.  Other  operators  must  be 
available  to  create  a  new  state.  For  every  state  created  following  the  initial  state,  a  best-preference  is  created 
for  the  superoperator  by  opsub*selcct-opsub*opcrator  to  try  out  the  operator  that  led  to  the  subgoal.  If  it 
generates  a  new  state  without  going  into  another  subgoal,  an  acceptable-preference  for  that  state  is  created 
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that  will  be  appropriate  to  the  supcrc»)ntext  by  opsub*detect-direct-opsub-suceess  or 
opsub*detect-indirect-opsub-success.  1  his  will  terminate  the  subgoal.  If  the  operator  leads  to  another  subgoal, 
it  is  rejected  by  opsub*rejcct-double-op-sub. 
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7.  Chunking 

Learning  in  Soar  is  based  on  building  productions  that  permanently  cache  the  processing  done  in  a  subgoal. 
The  actions  of  the  production  are  based  on  the  working-memory  elements  that  are  the  results  of  the  subgoal. 
l*he  conditions  of  the  productions  are  based  on  the  working-memory  elements  that  were  present  when  the 
subgoal  was  created  and  then  used  in  the  subgoal  to  create  the  results. 


A  number  of  factors  determine  whether  or  not  a  chunk  is  created  when  a  subgoal  is  terminated.  A  chunk  is 
built  unless  one  of  the  follow  ing  conditions  is  true: 

1.  Learning  is  off. 

2.  The  chunk  would  have  no  actions.  (This  attempts  to  guarantee  that  a  chunk  is  not  built  for  a 
subgoal  that  produces  no  results.  Such  a  situation  can  arise  when  a  supergoal  terminates  without 
the  termination  of  all  intermediate  subgoals.) 

3.  The  name  of  the  current  problem  space  of  the  subgoal  is  in  *chunk-free-problem-spaces*. 
(•Chunk-free-problem-spaces*  lets  the  user  control  which  problem  spaces  should  not  be  chunked. 

It  is  initially  empty,  so  that  all  problem  spaces  will  be  chunked.  One  strategy  is  only  to  learn 
search-control  knowledge  by  including  all  task  problem  spaces  in  *chunk-frec-problem-spaces*.) 

4.  None  of  the  conditions  of  the  chunk  have  a  class  in  •chunk-classes*.  *Chunk-classes*  is  set 
initially  to  (problem -space  state  operator).  This  prevents  the  creation  of  chunks  that  do  not  test 
any  of  the  objects  that  existed  before  the  subgoal  was  created.  These  chunks  are  usually  very 
overgencral. 

5.  Learning  is  bottom-up  and  a  chunk  was  built  for  a  subgoal  of  the  current  subgoal  (possibly  not  the 
immediate  subgoal). 

6.  The  chunk  is  a  duplicate  of  a  chunk  that  is  being  built  at  the  same  time.  The  detection  of 
duplicate  chunks  is  done  at  a  syntactic  level,  so  sometimes  chunks  that  are  semantically  equivalent 
to  previous  chunks  will  be  built. 


7.1 .  Determining  Conditions  and  Actions 

The  determination  of  the  conditions  and  actions  of  a  chunk-production  depends  on  the  creation  and 
reference  of  working-memory  elements  in  a  subgoal.  This  information  is  maintained  automatically  by  Soar 
for  each  working-memory  element  in  every  goal.  When  a  production  fires,  a  trace  of  the  production  —  the 
working-memory  elements  matched  by  its  conditions  and  created  by  its  actions  —  is  saved  on  the 
production-trace  property  of  the  appropriate  goal.  The  appropriate  goal  is  the  most  recently  created  goal 
(lowest  in  the  subgoal  hierarchy)  that  occurs  in  the  working-memory  elements  matched  by  the  production. 
Only  productions  that  actually  add  something  to  working  memory  have  their  traces  saved.  Therefore, 
productions  that  just  monitor  the  state  (have  only  write  statements)  will  not  aifcct  the  learning.  If  a 
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production  tries  to  add  working-memory  elements  that  already  exist,  it  will  not  affect  the  learning  (although 
sec  *chunk-all-paths*  for  an  alternative). 

Chunking  is  complicated  by  the  fact  that  context  slots  and  subgoal  augmentations  arc  created  by  the 
architecture  and  not  by  productions.  If  these  structures  arc  tested,  there  are  no  associated  conditions. 
Therefore.  Soar  asstxiatcs  with  them  those  working-memory  elements  that  arc  responsible  for  their  creation. 
Below  is  the  list  of  goal-context  augmentations  and  their  associated  pseudo-conditions. 

•  Problem  space,  state,  or  operator  roles.  The  acceptable-preference  for  the  object  in  the  role.  The 
other  preferences  arc  not  included  in  the  production  trace. 

•  Item  (for  tie  and  conflict  impasses).  The  acceptable-preference  for  the  object  in  the  item. 

•  Superoperator.  The  goal-context-info  for  the  operator  of  the  supergoal. 

•  Impasse  rejection.  All  the  reject-preferences  that  led  to  the  impasse. 

•  Impasse  no-change.  The  goal-context-info  for  the  next  slot,  with  undecided  as  the  value.  (This  is 
not  used  for  operator  no-change,  since  there  is  no  next  role.) 

•  Choices  none.  If  this  is  a  rejection  impasse,  all  the  reject-preferences  that  led  to  the  impasse.  If 
this  is  a  no-change  impasse 

Negated  conditions  of  ,'roductions  that  fire  in  a  subgoal  arc  included  in  a  trace  as  follows.  When  a 
production  fires,  its  negated  conditions  are  fully  instantiated  with  the  appropriate  values  for  its  variables 
based  on  the  rest  of  the  data  that  matched  the  production's  positive  conditions.  If  the  identifier  used  to 
instantiate  the  identifier  field  of  the  condition  was  created  before  the  subgoal,  then  the  instantiated  negated 
condition  is  added  to  the  trace  (as  a  negated  condition);  otherwise  it  is  ignored. 

The  actions  of  the  chunk  for  a  subgoal  arc  taken  to  be  those  working-memory  elements  created  in  the 
subgoal  (or  its  subgoals)  that  arc  accessible  from  the  supergoal.  An  augmentation  is  accessible  if  its  identifier 
existed  before  the  subgoal  was  created  or  is  in  another  result.  A  preference  is  accessible  if  all  of  its  non-nil 
context  objects  (goal,  problem  space,  state  and  operator)  existed  before  the  subgoal  was  created  or  is  in 
another  result.  Once  the  total  set  of  results  is  determined,  it  is  split  into  subgroups  such  that  no  two 
subgroups  share  objects  that  were  created  in  the  subgoal.  These  results  arc  logically  separate  and  can  be 
generated  in  the  future  by  separate  productions 

Once  the  actions  of  a  chunk  have  been  determined,  a  dependency  analysis  of  the  production  traces  is  used 
to  determine  exactly  those  working-memory  elements  that  existed  prior  to  the  creation  of  the  subgoal  that 
were  tested  in  creating  the  actions.  Not  all  working-memorv  elements  tested  in  a  subgoal  become  conditions 
in  a  chunk,  only  those  responsible  for  the  actions.  Specifically,  those  productions  that  created  non-acccptable- 
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preferences  will  usually  not  be  included  (unless  the  preferences  are  results  of  the  subgoal)  in  the  dependency 
analysis  because  they  contribute  only  to  the  decision  scheme.  For  the  decision  scheme,  only  acceptable- 
preferences  are  saved  in  production  traces.1 

7.2.  Replacing  Identifiers  with  Variables 

The  working-memory  elements  that  arc  used  to  create  the  conditions  and  actions  have  the  identifiers  of 
specific  objects  in  their  identifier  fields.  When  building  productions,  all  object  identifiers  are  replaced  by 
variables.  All  occurrences  of  an  identifier  are  replaced  with  the  same  variable.  This  sometimes  leads  to  a 
slightly  overspccific  chunk  (two  objects  that  did  not  have  to  be  the  same  in  the  subgoal,  but  just  happened  to 
be  the  same,  must  be  the  same  for  the  chunk  to  apply). 

7.3.  Removing  Extraneous  Conditions 

Soar  removes  conditions  where  the  identifier  in  the  value  field  does  not  occur  in  any  other  condition  or 
action  of  the  production.  This  process  recurs,  so  that  a  long  linkcd-list  of  conditions  (connected  by  value  and 
identifier  attributes)  will  be  removed  if  the  final  one  in  the  list  has  a  value  that  is  unique  to  that  condition. 
These  conditions  provide  little  or  no  constraint  on  the  match  and  greatly  increase  the  number  of 
instantiations. 

7.4.  Splitting  Chunks  Based  on  Duplicate  Conditions 

Following  the  removal  of  unnecessary  conditions,  it  is  possible  that  many  conditions  will  match  exactly  the 
same  working-memory  elements.  This  is  most  serious  when  substructures  are  copied  from  one  stale  to 
another.  To  eliminate  these  duplicate  conditions  ( which  cause  combinatorial  processing  in  the  matcher),  the 
production  is  split  into  multiple  productions.  Two  (or  more)  conditions  are  duplicates  if  they  are  exactly  the 
same  except  that  they  differ  in  the  rvalue  field.  In  addition,  the  identifiers  in  both  of  those  fields  must  not  be 
referenced  by  any  other  condition  and  must  be  referenced  by  actions.  It  is  assumed  that  these  conditions  are 
used  for  copying  structures  and  do  not  really  test  an  important  aspect.  One  of  these  conditions  is  saved  along 
with  the  actions  that  share  the  identifier  in  its  tvalue  field.  All  of  the  other  duplicate  conditions  and  the 
actions  that  share  the  identifiers  of  their  tvalue  field  are  eliminated.  More  than  one  set  of  duplicates  can 
occur  for  a  single  production,  and  a  list  is  maintained  of  the  representative  condition  and  actions  for  each  set 
of  duplicates. 

From  these  lists,  productions  will  be  created.  The  first  production  built  docs  everything  the  subgoal  did 
except  for  processing  the  duplicates.  Phis  production  does  not  contain  any  of  the  conditions  or  actions  that 
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were  duplicates.  Additional  productions  are  built  for  each  set  of  duplicates.  The  conditions  of  these 
productions  contain:(  l )  all  of  the  conditions  of  the  first  production;  (2)  all  actions  of  the  first  production  (so  it 
won't  fire  until  after  the  first  and  can  bind  to  all  identifier's  created  in  the  first  production);  and  (3)  the  one 
instance  of  a  duplicate  condition  saved  away.  The  actions  of  the  production  arc  only  those  actions  that  were 
saved  with  the  duplicate  condition.  Therefore,  for  one  subgoal,  many  productions  may  be  built. 

7.5.  Ordering  Conditions 

The  efficiency  of  the  Rete  matcher  used  in  Soar  is  heavily  dependent  on  the  order  of  the  conditions  in  the 
productions.  Therefore.  Soar  orders  the  conditions  in  an  attempt  to  make  the  matching  process  more 
efficient.  The  ordering  algorithm  is  implemented  by  trying  to  determine,  at  each  stage,  which  eligible 
condition,  if  placed  next,  will  have  the  fewest  number  of  instantiations  when  the  production  is  used.  The 
details  of  the  ordering  algorithm  are  given  in  the  Soar  Technical  Manual. 

7.6.  Making  Different  Variables  Distinct 

When  variables  were  assigned  to  conditions,  all  identical  identifiers  were  replaced  by  the  same  variable. 
However,  the  resuiting  production  could  match  the  same  identifier  to  different  variables,  so  that  the  semantics 
of  the  productions  are  incorrect.  Since  variables  in  OpsS  do  not  have  to  match  distinct  identifiers.  Soar 
explicitly  modifies  the  production  so  that  no  two  variables  can  match  the  same  identifier.  Soar  also 
automatically  modifies  any  goal-context-info  with  attribute  tproblem-space.  Estate.  or  toperator  that  has  a 
variable  in  its  value  field  that  does  not  appear  in  any  other  condition  (but  does  appear  in  an  action).  The 
modification  is  to  replace  the  variable,  say  <p>.  with  {  <>  undecided  <p>  }. 

7.7.  Refractory  Inhibition  of  Chunks 

When  a  production  is  built  as  a  part  of  a  chunk,  it  may  be  able  to  fire  immediately  on  those  working- 
memory  elements  that  were  used  to  create  it.  If  the  actions  of  the  production  include  the  creation  of  new 
objects,  the  production  will  immediately  fire  and  create  another  object,  in  addition  to  the  object  that  was  the 
original  result  of  the  subgoal.  To  avoid  this,  each  production  that  is  built  during  chunking  is  refracted  so  that 
it  will  not  fire  on  the  working-memory  elements  used  to  create  it.  T  his  does  not  prevent  a  newly  learned 
production  from  firing  on  other  working-memory  elements  that  arc  present. 

7.8.  Over-generalization 

Chunking  in  Soorcan  lead  to  over-generalization  in  three  ways,  first,  when  there  is  special-case  knowledge 
that  is  not  used  in  solving  a  subgoal.  I  his  knowledge  is  encoded  in  productions  for  which  most  but  not  all  of 
the  conditions  were  satisfied  during  a  problem-solving  episode.  Those  that  were  not  satisfied  cither  tested  for 
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the  absence  of  something  that  is  available  in  the  subgoal  (using  a  negated  condition)  or  for  the  presence  of 
something  missing  in  the  subgoal.  The  chunk  that  is  built  for  the  subgoal  may  be  over-general  because  it  does 
not  include  the  inverses  of  these  conditions.  During  a  later  episode,  when  all  of  the  conditions  of  a  special- 
case  production  would  be  satisfied  in  a  subgoal,  the  chunk  learned  in  the  first  trial  bypasses  the  subgoal.  If 
the  special-case  production  would  lead  to  a  different  result  for  the  goal,  the  chunk  is  over-general  and 
produces  an  incorrect  result. 

Overly  general  chunks  can  also  be  learned  when  there  are  negated  conditions  of  productions  in  a  subgoal 
that  test  for  the  absence  of  a  working-memory  element  that  would  be  created  in  the  subgoai.  If  the  creation  of 
that  working-memory  element  was  directly  related  to  the  existence  of  a  working-memory  clement  that  existed 
before  the  subgoal,  then  the  test  for  the  absence  of  the  working-memory  clement  local  to  the  subgoal  should 
be  replaced  by  a  test  for  the  absence  of  the  working-memory  element  that  existed  before  the  subgoal. 
Chunking  is  currently  unable  to  perform  such  an  analysis  and  include  tests  for  the  absence  of  working- 
memory  elements  unless  they  are  explicitly  made  in  a  production.  This  inability  can  lead  to  overly  general 
chunks. 

When  determining  the  conditions  of  a  chunk  via  the  dependency  analysis,  the  conditions  of  productions 
that  created  non-acceptable  preferences  are  included  only  if  they  were  results  of  the  subgoal,  or  the  results 
were  produced  based  on  them.  They  are  not  included  if  the  preferences  only  influenced  the  decisions  during 
the  problem  solving.  The  theory  is  that  these  productions  influence  the  efficiency  of  the  search,  but  do  not 
change  its  validity.  That  is  the  theory,  but  in  practice,  problem  spaces  can  be  implemented  that  depend  on 
productions  that  create  non-acceptable  preferences.  Instead  of  applying  all  tests  for  success  (the  goal  test)  to 
each  state  in  the  problem  space,  it  is  possible  to  move  some  of  the  goal  test  to  productions  that  reject 
intermediate  state  (or  operators)  that  do  not  satisfy  some  of  the  goal  constraints.  This  allows  the  final  goal  test 
to  be  much  simpler,  since  any  state  it  tests  is  guaranteed  to  satisfy  some  of  the  constraints  already.  In  these 
cases,  the  productions  created  by  chunking  are  overly  general  because  they  do  not  include  all  the  conditions 
they  should  since  only  the  final  goal  test  is  included  in  the  chunk,  and  not  the  implicit  tests  made  during  the 
search  that  guaranteed  that  a  valid  state  was  always  chosen. 
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8.  Encoding  a  Task 

I  his  chapter  describes  how  to  represent  goals,  problem  spaces,  states,  operators  and  search  control  for  a 
task  1716  fight  Puzzle  will  serve  as  an  example.  All  of  the  productions  will  be  in  SP  format,  and  these 
productions  will  actually  perform  the  task.  The  productions  will  be  given  in  lower-case,  which  is  appropriate 
for  all  systems  except  lateriisp. 

8.1 .  Problem  Space  Decomposition 

Ihe  first  step  in  encoding  a  task  in  Soar  is  to  decompose  it  into  a  set  of  problem  spaces.  This  is  a  difficult 
step  and  corresponds  to  structuring  the  task.  However,  only  a  single  problem  space  is  necessary  to  represent 
and  solve  the  Kight  Puzzle.  T  his  problem  space  consists  of  states  that  have  different  configurations  of  eight 
numbered  tiles  in  a  3x3  frame  and  operators  that  move  tiles  adjacent  to  the  blank  space  into  the  blank  space. 
In  contrast.  Rl-Soar  has  a  hierarchy  of  up  to  ten  different  problem  spaces.  Such  a  hierarchy  arises  when  the 
operators  of  one  problem  space  require  a  second  problem  space  for  their  implementation.  The  operators  of 
the  high-level  problem  spaces  are  not  implemented  directly  by  productions,  but  instead  are  implemented  by 
other  operators  in  other  problem  spaces.  At  some  point  the  hierarchy  bottoms  out,  and  the  operators  are 
implemented  directly  by  productions. 

As  of  yet.  there  are  no  hard  and  fast  rules  for  decomposing  a  problem  into  multiple  problem  spaces.  It  is 
never  necessary  to  decompose  a  task  into  separate  problem  spaces  because  every  hierarchy  of  problem  spaces 
can  be  represented  as  a  single  problem  space,  with  search-control  knowledge  that  simulates  the  control 
achieved  through  decomposition  into  separate  problem  spaces.  With  decomposition,  it  is  often  possible  to 
represent  a  task  as  a  set  of  problem  spaces  with  little  or  no  search  control.  Problem  space  decomposition  is 
possible  when  different  aspects  of  the  state  of  the  task  can  be  modified  independently  of  other  parts  of  the 
state,  or  when  different  sets  of  operators  are  selected  together,  independently  of  other  operators.  The  sets  of 
operators  that  act  independently  can  then  be  grouped  into  separate  problem  spaces.  These  problem  spaces  are 
then  selected  in  response  to  no-change  impasses  for  a  high-level  operator  that  represents  the  problem  solving 
that  will  occur  in  the  subgoal. 

8.2.  States 

As  in  a  standard  programming  language,  the  next  step  in  designing  and  implementing  a  task  is  deciding  on 
a  representation  of  the  data  being  manipulated.  In  Soar ;  this  involves  defining  the  representation  of  the  states 
of  the  problem  spaces.  Given  the  available  attribute- value  scheme,  many  different  representations  arc 
possible  for  a  given  task.  One  structural  restriction  is  that  all  substructure  of  a  state  must  be  linked  to  the 
state,  either  directly  (through  a  single  augmentation),  or  indirectly  (through  a  chain  of  augmentations).  Ihe 
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augmentations  then  form  a  directed  lattice,  where  the  identifier  of  the  state  is  the  root 

The  representation  of  the  states  has  a  large  impact  on  the  efficiency  and  the  generality  of  problem  solving 
and  learning.  From  our  experience,  efficiency  and  generality  is  maximized  if  the  implementations  of 
operators  and  search  control  arc  able  to  test  and  create  only  those  aspects  of  the  problem  that  are  necessary  to 
perform  the  required  functions.  There  arc  two  general  rules  for  implementing  this  principle. 

1.  Hvery  piece  of  information  that  is  relevant  to  the  problem  solving  should  be  represented 
explicitly,  cither  as  an  object,  as  the  augmentation  of  an  object,  or  in  the  structure  of  a  set  of 
augmentations.  This  removes  the  need  for  complex  condition  predicates  that  can  detect  implicit 
information,  such  as  comparing  two  absolute  positions  given  in  a  coordinate  system  and  detecting 
that  they  arc  adjacent.  If  a  piece  of  information  is  not  represented  explicitly,  the  testing  or 
creation  of  that  information  will  involve  testing  or  creating  other  information.  (If  only  the 
absolute  positions  are  explicitly  represented,  the  absolute  positions  must  be  tested  to  determine 
adjacency. ) 

2.  Dynamic  and  static  information  should  be  represented  separately,  minimizing  the  amount  of 
information  that  is  dynamic.  Dynamic  information  (data  that  can  be  changed  by  operators)  should 
be  represented  by  augmentations  of  the  state.  If  the  static  information  is  tied  directly  to  the  state, 
it  must  be  explicitly  copied  from  state  to  state.  When  possible,  static  information  (data  that  is  not 
changed  by  operators)  should  be  represented  by  augmentations  of  dynamic  information.  By 
making  this  separation,  the  static  information  is  unchanged  by  operator  application,  minimizing 
the  amount  of  processing  required  to  apply  an  operator.  If  the  static  information  is  tied  directly  to 
the  state,  it  must  be  explicitly  copied  from  state  to  state. 

Let’s  apply  these  two  principles  to  the  Fight  Puzzle.  In  this  example,  there  is  only  a  single  problem  space. 
When  there  are  multiple  problem  spaces  that  share  the  same  data  structures,  the  application  of  these  rules  is 
more  problematic  because  information  that  is  static  in  one  problem  space  may  be  dynamic  in  another. 

In  determining  an  appropriate  representation,  the  operators  of  a  problem  space  must  be  considered  because 
they  determine  what  information  is  necessary  to  solve  the  problem  and  whether  the  information  is  dynamic  or 
static.  Consider  the  Fight  Puzzle,  which  consists  of  a  3x3  frame  with  eight  tiles,  labelled  1-8.  and  a  blank 
space.  The  nine  positions  that  contain  the  tiles  are  called  cells.  The  operators  of  the  problem  space  move  a 
tile  in  a  cell  adjacent  to  the  blank  space  into  the  cell  with  the  blank.  A  problem  is  to  start  at  some  initial 
configuration  and.  through  a  series  of  tile  movements,  obtain  some  desired  configuration.  Figure  8-0  contains 
an  example  initial  and  desired  state. 

To  derive  a  representation  that  obeys  both  of  the  representational  rules,  we  first  determine  the  information 
that  is  used  in  solving  the  problem  and  therefore  must  be  explicitly  represented.  I  wo  types  of  knowledge  are 
a  necessary  part  of  problem  solving:  (1)  operator-implementation  knowledge,  and  (2)  goal-test  knowledge. 
Kach  of  these  test  different  aspects  of  the  state.  Below  is  a  list  of  the  information  required  to  implement  the 
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figure  8- 1 :  Kight  Puzzle  initial  and  desired  states. 

task. 

1.  The  relative  positions  of  the  tiles  and  the  blank.  These  arc  needed  to  determine  if  a  tile  is  next  to 
the  blank  so  that  the  tile  can  be  moved:  operator-implementation  knowledge. 

2.  The  absolute  positions  of  the  tiles  and  the  blank.  These  are  needed  to  determine  if  the  tiles  arc  in 
the  same  cells  as  those  in  the  desired  state:  goal-test  knowledge. 

3.  The  numbers  on  the  tiles.  I  hese  are  needed  to  determine  if  the  tiles  arc  in  the  same  position  as 
those  in  the  desired  state:  goal-test  knowledge. 

The  next  issue  is  to  minimize  the  amount  of  dynamic  data  that  must  be  modified  when  an  operator  applies. 
When  an  operator  is  applied,  it  changes  neither  the  tile,  nor  the  cell  that  it  occupied.  All  it  changes  is  the 
relationship  between  the  tile  and  two  cells  on  the  board  (the  cell  where  it  was  and  the  cell  that  it  now 
occupies).  We  can  reify  that  relationship  and  represent  it  as  an  object.  Once  the  rclauonship  is  an  object,  the 
operators  need  only  manipulate  the  relationship  and  not  the  other  objects,  l  et’s  call  the  relationship  a 
binding,  since  it  represents  a  binding  of  the  tile  to  a  specific  cell.  Ihercforc.  a  state  consists  of  a  set  of  nine 
bindings  one  for  each  of  the  tile  and  cell  combinations.  Each  binding  has  an  augmentation  for  a  tile  and  a  cell. 
Each  tile  is  augmented  with  the  number  on  it.  while  each  cell  is  augmented  with  its  absolute  position.  To 
represent  the  relative  positions  of  the  cells  (so  that  the  relative  position  of  the  tiles  can  be  determined),  the 
cells  are  also  augmented  with  their  adjacent  cells.  All  the  dynamic  information  is  encoded  as  bindings,  while 
all  of  the  static  information  is  encoded  in  the  tile  and  cell  objects.  The  operators  will  only  manipulate 
bindings,  and  never  modify  the  ule  or  cell  objects.  To  improve  the  efficiency  of  some  of  the  matches,  the  state 
is  also  augmented  directly  with  the  binding  for  the  blank  (tblank-binding)  and  the  binding  of  the  tile  that  was 
just  moved  (tmoved-tile-binding).  Below  are  a  set  of  actions  that  create  a  state  in  this  format. 
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(state  <s>  tblank-binding  <bb5>  tbinding  <bbO>  <bbl>  <bb2>  <bb3> 
<bb4>  <bb5>  <bb6>  <bb7>  <bb8>  tblank  <c23>) 

(binding  <bbO>  tcell  <cll>  ttile  <t2>) 

(cell  <cll>  tname  11  tcell  <cl2>  tcell  <c21>) 

(tile  <t2>  tname  2) 

(binding  <bbl>  tcell  <cl2>  ttile  <tl>) 

(cell  <cl2>  tname  12  tcell  <cll>  tcell  <cl3>  tcell  <c22>) 

(tile  <tl>  tn ame  1 ) 

(binding  <bb2>  tcell  <cl3>  ttile  < 1 7 > ) 

(cell  <cl3>  tname  13  tcell  <cl2>  tcell  <c23>) 

(tile  <t7>  tname  7) 


In  addition  to  the  two  rules  stated  earlier,  there  are  three  special  cases  of  them  that  should  be  kept  in  min 
when  creating  state  representations. 

1.  A  constant  can  be  tested  in  two  different  ways  by  the  productions  used  in  solving  a  problem, 
hirst,  a  production  may  test  that  a  constant  is  a  specific  value,  in  which  case  the  constant  would 
appear  in  the  conditions  of  the  production.  In  this  case,  the  problem  solving  is  dependent  on  that 
specific  value,  and  any  chunk  built  to  summarize  the  problem  solving  would  correctly  contain  that 
constant.  In  the  second  case,  a  production  may  test  if  two  different  objects  have  the  same  constant 
(an  equality  test).  I  his  test  is  performed  by  matching  both  constants  by  the  same  variable.  In  this 
case,  the  problem  solving  is  independent  of  the  specific  values  of  the  constants,  being  dependent 
only  on  the  fact  that  they  are  equal  (or  not  equal).  A  chunk  would  nevertheless  include  the 
specific  constants  because  the  constant  is  being  functionally  overloaded,  with  its  specific  value, 
and  its  equality  relation  to  other  constants.  'Hie  solution  to  this  problem  is  to  have  indirect 
pointers  to  constants  when  they  will  be  used  in  equality  tests.  In  our  example,  the  tile  numbers 
were  not  contained  in  the  binding  augmentations  of  the  state  but  were  represented  indirectly  in 
the  tile  objects.  The  tile-object  identifiers  can  then  be  compared  for  equality,  without  referencing 
the  exact  values  of  the  tile  names.  One  useful  convention  is  that  constants  should  appear  as  values 
only  in  tname  augmentations.  All  other  augmentations  should  be  the  identifier  of  another  object 
that  has  a  further  description. 

2.  All  functionally  independent  uses  of  a  concept  should  be  represented  as  separate  objects.  IX)  not 
overload  an  attribute  or  value  with  many  different  uses.  Hath  use  should  be  represented 
separately,  for  example,  if  the  state  contains  the  description  of  an  algebra  problem,  it  might  have 
the  concept  left  used  in  two  different  contexts,  to  represent  expressions  on  the  left  side  of  equals 
sign  and  to  represent  terms  on  the  left  side  of  another  operator,  such  as  plus.  These  two  lefts  are 
functionally  independent.  However,  if  both  of  these  are  tested  in  a  problem  solving  episode,  the 
resulting  chunks  will  contain  tests  making  them  dependent.  I  hat  is.  any  tests  concerning  the  sides 
of  the  equation  will  be  dependent  on  tests  of  sides  of  the  operator.  I  his  arises  because  chunking 
assumes  that  if  the  same  identifier  is  used  in  multiple  places  on  this  case,  the  identifier  of  the 
object  named  left),  then  a  chunk  must  test  that  it  is  the  same,  even  though  in  this  example  it  did 
not  have  to  be  the  same. 


3.  If  a  disjunction  is  used  in  i  condition  of  a  production,  say  for  the  names  of  two  problem  spaces 
(such  as  «  problem-space-one  problem-space-two  >>).  a  chunk  that  included  a  tiring  of  that 
production  would  include  a  test  for  onlv  one  ot  the  two  names,  not  both.  I  his  would  make  the 
chunk  less  general  than  necessary  I  o  solve  this  problem  reifv  the  disiunciion  and  create  another 
augmentation  for  both  problem  spaces  and  then  test  tor  that  augmentation.  I  his  is  exactly  the 
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reason  that  there  is  a  tchoices  augmentation  for  goals.  Many  productions  used  to  test  for 
timpasse  «  tie  conflict  »  or  timpasse  «  no-change  rejection  »  and  the  chunks  built  for  the 
subgoals  would  be  ovcr-spccific.  By  adding  the  tchoices  augmentation,  a  single  augmentation  can 
be  tested  that  embodies  the  disjuncuon;  and  the  disjunction  is  then  included  in  the  chunks. 


8.3.  Operator  Creation 

Once  a  representation  for  the  states  has  been  designed,  the  problem-space  operators  should  be  defined.  For 
a  given  problem,  many  different  sets  of  operators  may  be  possible  for  essentially  the  same  problem  space.  For 
the  Fight  Puzzle,  there  could  be  twenty-four  operators,  one  for  each  possible  movement  from  each  cell  to  an 
adjacent  cell.  In  such  an  implementation,  all  operators  could  be  made  acceptable  for  each  state  and  then  all  of 
those  that  cannot  apply  because  the  blank  is  not  in  the  appropriate  place  would  be  rejected.  A  convention  in 
Soar  is  that  if  a  problem  space  is  augmented  with  an  operator  (such  as  (problem-space  p0003  ^operator 
00002)).  an  acceptable-preference  for  that  operator  w  ill  automatically  be  made  so  that  the  operator  will  be 
considered  for  every  state  in  the  problem  space  (by  production  default*make-all-operators-acceptable). 
Alternatively,  only  those  operators  that  arc  applicable  to  a  state  could  be  made  acceptable,  which  wc  will 
describe  in  our  example  below.  Another  implementation  could  have  four  operators,  one  for  each  direction 
that  tiles  can  be  moved  into  the  blank,  up.  down,  left,  and  right.  Those  operators  that  do  not  apply  to  a  state 
(because  no  tile  exists  that  can  be  moved  in  that  direction)  could  be  rejected. 


In  our  implementation  of  the  Eight  Puzzle,  there  is  a  single  general  operator,  which  moves  a  tile  adjacent  to 
the  blank  into  the  blank.  For  a  given  state,  instantiations  of  this  operator  are  created  for  each  of  the  adjacent 
tiles.  To  create  the  operator  instantiations  requires  a  single  production,  shown  below.  Each  operator  has 
three  fields:  tname  contains  the  name  of  the  operator,  which  is  always  move-tile:  tblank-cell  for  the  cell  that 
contains  the  blank;  and  ttile-cell  for  the  cell  that  contains  the  tile  that  will  be  moved  into  the  cell  with  the 
blank.  At  the  same  time  that  an  operator  is  created,  an  acceptable-preference  is  created,  so  that  the  operator 
can  be  selected  to  be  the  current  operator  for  the  context  containing  the  eight-puzzle  problem  space  and  the 
state  with  which  the  operator  was  instantiated.  Since  operators  are  created  only  if  they  can  apply,  no 

additional  production  is  required  to  reject  inapplicable  operators. 

(sp  eight'acceptable 

(gc  <g>  tprobl em-space  <p>  tstate  <s>) 

(problem-space  <p>  tname  eight-puzzle) 

(state  <s>  tblank-b inding  <blank>) 

(binding  <blank>  tcell  <cl>) 

(cell  <cl>  tee  1 1  <c2> ) 

-(preference  trole  operator  rvalue  acceptable 
tgoal  <g>  rproblem-space  <p>  tstate  <.s>) 

--> 

(operator  <o>  tname  move-tile  ttile-cell  <c2>  tblank-cell  <cl>) 
(preference  <o>  trole  operator  tvalue  acceptable 
tgoal  <g>  tproblem-space  cp>  tstate  ss>)) 
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8.4.  Operator  Application 

An  operator  of  a  problem  space  is  applied  when  it  is  selected  by  the  decision  procedure,  i.e.,  when  its 
identifier  replaces  the  existing  symbol  in  the  role  of  an  operator,  t  hat  is.  whatever  happens  while  a  given 
identifier  occupies  an  operator  role  comprises  the  attempt  to  apply  that  operator.  Selecting  an  operator  and 
installing  its  identifier  in  the  operator  role  produces  a  context  in  which  productions  associated  with  the 
operator  can  execute  (they  contain  a  condition  that  tests  that  the  operator  is  selected).  Operator  productions 
are  just  elaboration  productions,  used  for  operator  application  rather  than  for  search  control. 

When  a  nonmonotonic  operator  (an  operator  that  modifies  the  current  state)  is  successfully  applied,  it  must 
create  a  preference  for  the  new  state  it  creates.  That  preference  includes  the  current  goal,  problem  space,  state 
and  operator.  Based  on  this  preference,  the  new  state  can  be  selected:  and  the  operator  will  not  be  re-applied 
to  the  state  (default*no-operator-retry  will  reject  the  operator).  If  the  operator  is  monotonic  (only  adds 
information  to  the  state)  or  fails  to  apply,  it  should  create  a  new  preference  for  the  current  state,  which  then 
leads  to  the  operator  s  rejection  (by  default*no-operator-retry). 


To  apply  an  instantiated  operator  in  the  Right  Puzzle  requires  the  two  productions  shown  below.  When  the 
identifier  of  a  move-tile  operator  is  selected  as  an  operator  in  the  eight-pu/zle  problem  space,  production 
eight*create-new-state  will  apply  and  create  a  new  state  with  the  moved  tile  and  the  blank  in  their  new 
positions.  It  detects  that  there  is  an  operator  in  the  operator  role  and  matches  the  binding  Khl»  for  the 
blank  tile  «tl»  and  its  cell  «cl».  It  also  matches  the  ceil  that  is  connected  to  <cl>  via  the  operator  «c2>) 
and  matches  the  tile  in  that  cell  (<t2».  The  actions  of  the  production  arc  to  create  a  new  state  symbol  Ks2». 
a  preference  for  that  state  (with  the  current  context  in  its  context  fields),  and  then  swap  the  bindings  of  cell 
<cl>  and  <c2>.  It  marks  in  the  state  the  bindings  that  were  swapped  (tswapped)  and  the  bindings  that  were 
just  created,  distinguishing  the  old  and  new  positions  of  the  moved  tile  (tblank-binding.  tmoved-tile-binding). 

These  latter  augmentations  will  be  used  by  search  control. 

(sp  eight*create-new-state 

(gc  <g>  tproblem-space  <p>  tstate  <s>  ^operator  <o>) 

(problem-space  <p>  tname  eight-puzzle) 

(state  <s>  tbinding  <bl>  tbinding  <b2>  tblank-binding  <bt>) 

(binding  <bl>  ttile  <tl>  tcell  <cl>) 

(binding  <b2>  ttile  <t2>  tcell  <c2>) 

(operator  <o>  tname  move-tile  tblank-cell  <cl>  ttile-cell  <c2>) 

--> 

(preference  <s2>  trole  state  tvalue  acceptable 

tgoal  <g>  tproblem-space  <p>  tstate  <s>  toperator  <o>) 

(state  <s2>  tswapped  <bl>  tswapped  \b2>  tpi ank-b  ind i ng  <b3> 
tmoved-tile-binding  <b4>  tbinding  <b3>  tbinding  <b4>) 

(binding  <b3>  ttile  <"t2>  tcell  <  c  1  > ) 

(binding  <b4>  ttile  <tl>  tcell  <  c  2  >  ) ) 

A  second  production.  eight*copy-unchanged.  copies  over  all  of  the  bindings  that  did  not  have  to  be  vwapped. 


ENCODING  A  I  ASK 


47 


(t  applies  after  the  previous  production  by  testing  for  the  creation  of  the  preference  for  the  new  state  (created 
by  eight*create-new-state).  The  test  of  the  preference  must  include  tests  that  the  state  and  operator  are  not 
equal  to  nil,  because  even  though  <s>  and  <o>  were  previously  bound  in  the  first  conditions,  the  preference 
will  match  if  its  context  fields  match  exactly  or  match  nil  (so  that  it  is  easy  to  match  those  preferences  that  arc 

relevant  to  a  context). 

(sp  e ight*copy-unchanged 

(gc  <g>  tproblem-space  <p>  t$tate  <s>  toperator  <o>) 

(problem-space  <p>  tname  eight-puzzle) 

(preference  <n>  trole  state  tvalue  acceptable 
tproblem-space  <p>  tstate  {  <>  nil  <s>} 
toperator  {  <>  nil  <o>}) 

(state  <s>  tbinding  <b>) 

(operator  <o>  tname  move-tile) 

(state  <n>  -tswapped  <b>) 

--> 

(state  <n>  tbinding  <b>)) 

l his  production  and  the  previous  one  are  typical  of  the  types  of  productions  used  to  implement  simple 
operators  in  Soar.  One  production  makes  the  changes  and  creates  a  new  state,  while  another  (or  possibly 
others)  copies  those  aspects  of  the  state  unaffected  by  the  operator.  This  shows  how  to  implement  an  operator 
that  changes  or  adds  new  augmentations  to  a  state.  If  an  operator  is  to  delete  some  aspect  of  a  state,  the 
productions  that  implement  it  should  create  a  new  state  and  copy  only  those  augmentations  that  arc  to  be 
retained. 

8.5.  Goal  Detection 

All  subgoals  are  terminated  by  the  architecture,  which  detects  the  resolution  of  an  impasse  through  the 
creation  of  new  preferences.  So,  in  one  sense,  goal  detection  is  done  automatically.  However,  for  many 
subgoals  (and  usually  the  top-level  goal),  the  decision  to  create  a  preference  that  resolves  the  impasse  becomes 
equivalent  to  a  goal  test.  In  addition,  when  an  evaluation  subgoal  is  used,  it  is  useful  to  be  able  to  signify  that 
a  state  created  in  the  subgoal  will  achieve  a  higher-level  goal.  Therefore,  there  is  default  knowledge  in  Soar 
that  detects  when  a  state  is  augmented  with  success  or  failure  with  respect  to  a  given  desired  state.  These  rules 
create  the  appropriate  preferences  if  it  is  a  subgoal,  or  terminates  problem  solving  if  it  is  in  the  top-level  goal 
(see  Section  6.4). 

In  detecting  that  a  state  achievr.;  a  goal,  the  actual  test  can  be  represented  either  explicitly  or  implicitly. 
Sometimes  the  desired  stars  are  represented  explicitly  as  an  augmentation  of  the  goal.  I  his  augmentation 
would  usually  be  created  after  the  problem  space  has  been  selected.  Alternatively,  the  desired  states  may  not 
be  explicitly  represented;  and  instead  there  may  be  a  production,  a  set  of  productions,  or  an  operator  that 
recognize  when  a  given  state  satisfies  the  goal  without  comparing  it  to  an  explicit  description.  There  can  be 
any  level  of  explicit  or  implicit  representation  in  between  where  parts  of  the  desired  state  are  explicitly 
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represented,  and  parts  of  the  goal  test  are  embedded  in  productions.  However,  the  satisfaction  of  a  goal 
should  be  detected  by  a  test  of  a  state  (including  its  augmentations)  and  the  information  ued  to  the  goal.  If 
other  information  is  tested  (such  as  aspects  of  the  problem  space  or  the  operator),  then  that  information 
belongs  either  in  the  goal  or  in  the  state.  Whenever  the  goal  is  augmented  with  additional  information  to  be 
used  in  the  goal  test,  it  should  be  encoded  as  an  object  that  is  the  value  of  the  tdesired  augmentation  of  the 
goal. 

Although  Soar  allows  the  detection  of  desired  states  through  recognition  by  a  production  (without 
comparison  to  an  explicitly  represented  desired  state),  it  is  not  the  recommended  practice  because  it  leads  to 
the  learning  of  overly  specific  chunks.  The  production  that  tests  for  the  desired  state  must  include  conditions 
that  test  for  the  actual  v  alues  of  the  constants  in  the  state.  In  the  Tight  Puzzle  this  would  mean  testing  that  a 
specific  cell  had  a  specific  tile.  Any  chunk  built  to  summarize  the  subgoal  in  which  the  test  applied  would  be 
specific  to  the  exact  desired  state.  Instead,  a  comparison  can  be  done  between  an  explicitly  represented 
desired  state  and  the  current  state.  In  this  case,  only  the  equality  of  the  identifiers  that  are  augmented  with 
the  constants  need  be  tested,  and  not  the  constants  themselves.’  t  he  resulting  chunk  is  sensitive  to  the 
relative  values  of  the  desired  state  and  the  slates  in  the  problem  space  and  not  the  exact  values  of  the  constants 
in  the  state. 

For  the  Tight  Puzzle,  the  desired  state  is  explicitly  represented  in  working  memory  as  a  state.  Hie  desired 
state  «d>)  is  in  tdesired  augmentations  of  the  goal.  The  following  production  detects  that  the  desired  state 
has  been  achieved. 


“I his  assumes  that  it  is  possible  to  coordinate  the  states  and  the  desired  -.me  in  the  problem  ,pa.  c  no  that  ihe\  share  the  same 
identifiers  tor  the  constants  this  is  not  always  possiole 
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(sp  e ight*detect-goal 

(gc  <g>  tproblem-space  <p>  tstate  <s>  tdesired  <d>) 

(space  <p>  tname  eight-puzzle) 

(state  <s>  ^binding  <xll>  <xl2>  <xl3>  <x21>  <x22>  <x23> 
<x31>  <x32>  <x33> ) 

(binding  <xll>  tcel 1  <cll>  t t i  1 e  <oll>) 

(binding  <xl2>  tcell  <cl2>  ttile  <ol2>) 

(binding  <xl3>  tcell  <cl3>  ttile  < o 1 3 > ) 

(binding  <x21>  tcell  <c21>  ttile  <o21>) 

(binding  <x22>  tcell  <c22>  ttile  <o22>) 

(binding  <x23>  tcell  <c23>  ttile  <o23>) 

(binding  <x31>  tcell  <c31>  ttile  <o31>) 

(binding  <x32>  tcell  <c32>  ttile  <o32>) 

(binding  <x33>  tcell  <c33>  ttile  <o33>) 

(cell  <cll>  tname  11)  (cell  <cl2>  tname  12) 

(cell  <cl3>  tname  13)  (cell  <c21>  tname  21) 

(cell  <c22>  tname  22)  (cell  <c23>  tname  23) 

(cell  <c31>  tname  31)  (cell  <c32>  tname  32) 

(cell  <c33>  tname  33) 

(desired  <d>  tbinding  <dll>  <dl2>  <dl3>  <d21>  <d22>  <d23> 
<d31>  <d32>  <d33> ) 

(binding  <dll>  tcell  <cll>  ttile  <oll>) 

(binding  <dl2>  tcell  <cl2>  ttile  <ol2>) 

(binding  <dl3>  tcell  <cl3>  ttile  <ol3>) 

(binding  <d21>  tcell  <c21>  ttile  <o21>) 

(binding  <d22>  tcell  <c22>  ttile  <o22>) 

(binding  <d23>  tcell  <c23>  ttile  <o23>) 

(binding  <d31>  tcell  <c31>  ttile  <o3l>) 

(binding  <d32>  tcell  <c32>  ttile  <o32>) 

(binding  <d33>  tcell  <c33>  ttile  <o33>) 

--> 

(state  <s>  tsuccess  <d>)) 


The  action  is  to  augment  the  state  with  tsuccess  and  the  value  of  tdesired.  By  including  the  desired,  this 
guarantees  that  only  those  goals  that  share  the  same  desired  state  will  be  terminated.  Default  productions 
handle  tsuccess.  so  that  if  a  top-goal  is  detected  in  a  subgoal  (and  labeled  with  tsuccess).  evaluations  and 
selection  subgoais  are  handled  correctly.  See  Section  6.4  for  more  information  on  evaluations. 


In  this  example,  the  test  was  performed  with  a  single,  very  large  production.  Other  options  are  possible:  (1) 
test  each  of  the  bindings  of  a  state  independently  in  parallel,  and  then  combine  the  results  of  those  tests:  or  (2) 
test  the  initial  state  and  then  incrementally  update  the  comparison  based  on  the  changes  made  to  the  state. 


For  many  problems,  the  generality  of  chunks  learned  by  Soar  is  maximized  if  the  goal  test  is  done 
incrementally.  An  incremental  goal  test  involves  keeping  track  of  the  differences  between  a  state  and  me 
desired  state.  When  a  new  state  is  created,  its  differences  are  computed  based  on  the  differences  in  the  state  it 
was  created  from  and  any  changes  to  the  prior  state  that  were  necessary  to  create  the  new  state.  W  hen  there 
are  no  differences  between  a  state  and  the  desired  state,  the  goal  is  achieved.  This  improves  the  generality  of 
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the  conditions  of  a  chunk  built  for  the  goal  because  the  detection  of  goal  achievement  is  based  only  on  the 
parts  of  a  state  that  changed,  and  not  on  the  complete  state.  When  non-incremental  goal  tests  are  used,  the 
complete  state  must  be  tested,  not  just  the  aspects  that  changed.  Not  all  goals  can  be  tested  incrementally, 
although  any  goal  that  has  a  conjunction  of  conditions  can  be.  In  the  Eight  Puzzle,  the  position  of  each  tile  in 
its  desired  cell  can  be  detected  independently  and  an  incremental  goal  test  can  be  used.  When  the  initial  state 
is  selected,  it  is  augmented  with  a  difference  that  is  the  number  of  tiles  that  are  out  of  place.  Whenever  a  new 
state  is  created,  its  difference  would  be  computed  modifying  the  difference  of  its  prior  state  to  reflect  the 
changes  in  the  new  state  (a  tile  is  moved  into  or  out  of  its  desired  cell). 

8.6.  Initialization 

In  addition  to  defining  the  operator  selection,  operator  application  and  goal  detection  rules,  working 
memory  must  be  initialized  to  an  appropriate  goal,  problem  space  and  initial  state,  so  that  problem  solving 
can  begin.  Following  a  call  to  init-soar.  working  memory  is  empty.  When  Soar  starts  with  an  empty  working 
memory,  a  context  is  created  that  has  all  of  the  slots  set  to  undecided.  This  context  does  not  have  a  supergoal. 

One  way  to  get  a  task  started  (as  in  eight*start  below),  is  to  use  a  production  that  detects  a  goal  without  a 

supergoal,  and  creates  a  preference  for  a  new  problem  space,  in  this  case,  one  named  eight-puzzle.  Since  the 

variable  <p>  only  appears  in  the  action,  it  will  be  bound  to  a  newly  generated  symbol,  starting  with  the  first 

letter  of  the  variable  (something  like  P0034).  The  second  occurrence  of  <p>  (in  the  preference)  will  use  this 

same  symbol.  The  goal  is  augmented  with  a  name  that  can  be  tested  by  later  productions. 

(sp  eight*start 

(gc  <g>  tproblem-space  undecided  'tsupergoal) 

(gc  <g>  timpasse  none  tname  sol ve-eight-puzzle) 

(problem-space  <p>  tname  eight-puzzle) 

(preference  <p>  trole  problem-space  tvalue  acceptable 
tgoal  <g>)) 

The  preference  created  to  select  a  problem  space  is  only  sensitive  to  the  current  goal. 

Another  type  of  initialization  is  available  using  the  init-context  function,  which  allows  the  user  to  set  the 
values  of  the  top  context  (see  Section  10.2.3). 

Production  eight*initial-desired-states  creates  the  initial  and  desired  state  as  well  as  a  preference  for  the 
initial  state.  The  acceptable-preference  for  the  initial  state  «s>)  has  undecided  in  the  state  field  so  that  this 
state  will  be  selected  only  at  the  beginning  of  problem  solving.  If  the  state  field  were  unspecified  (or  nil),  the 
acceptable-preference  wouid  make  the  state  a  candidate  at  all  times  during  problem  sob  ing  in  goal  <g>  and 
problem  space  <p>.  since  a  preference  is  used  whenever  all  of  its  non-nil  context  fields  match  the  roles  of  a 
context 
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(sp  eight* initial -desired-states 

(gc  <g>  rproblem-space  <p>  tstate  undecided 
tname  sol ve-eight-puzzle) 

(problem-space  <p>  tname  eight-puzzle) 

--> 

(gc  <g>  tdesired  <d>) 

(preference  <s>  trole  state  tvalue  acceptable 

tgoal  <g>  tproblem-space  <p>  tstate  undecided) 

(state  <s>  tbinding  <bbO>  <bbl>  <bb2>  <bb3> 

<bb4>  <bb5>  <bb6>  <bb7>  <bb8>  tblank-binding  <bb5>) 

(binding  <bbO>  tcell  <cll>  ttile  <t2>) 

(binding  <bbl>  tcell  <cl2>  ttile  <tl>) 

(binding  <bb2>  tcell  <cl3>  ttile  <t7>) 

(binding  <bb3>  tcell  <c21>  ttile  <t8>) 

(binding  <bb4>  tcell  <c22>  ttile  <t6>) 

(binding  <bb5>  tcell  <c23>  ttile  <t0>) 

(binding  <bb6>  tcell  <c31>  ttile  <t3>) 

(binding  <bb7>  tcell  <c32>  ttile  <t4>) 

(binding  <bb8>  tcell  <c33>  ttile  <t5>) 

(desired  <d>  tbinding  <d0>  <dl>  <d2>  <d3>  <d4> 

<d5>  <d6>  <d7 >  <d8> ) 

(evaluation  <d>  tbetter  higher) 

(binding  <dl>  tcell  <cll>  ttile  <tl>) 

(binding  <d2>  tcell  <cl2>  ttile  <t8>) 

(binding  <d3>  tcell  <cl3>  ttile  < 1 7 > ) 

(binding  <d8>  tcell  <c21>  ttile  <t2>) 

(binding  <d0>  tcell  <c22>  ttile  <t0>) 

(binding  <d4>  tcell  <c23>  ttile  <td>) 

(binding  <d7>  tcell  <c31>  ttile  <t3>) 

(binding  <d6>  tcell  <c32>  ttile  <t4>) 

(binding  <d5>  tcell  <c33>  ttile  <t5>) 

(cell  <cll>  tname  11  tcell  <cl2>  tcell  <c21>) 

(cell  <cl2>  tname  12  tcell  < c 1 1  >  tcell  <cl3>  tcell  <c22>) 

(cell  <cl3>  tname  13  tcell  <cl2>  tcell  <c23>) 

(cell  <c21>  tname  21  tcell  < c 1 1 >  tcell  <c31>  tcell  <c22>) 

(cell  <c22>  tname  22  tcell  <c21>  tcell  <cl2>  tcell  <c23>  tcell  <c32>) 

(cell  <c23>  tname  23  tcell  <c22>  tcell  <c33>  tcell  <cl3>) 

(cell  <c31>  tname  31  tcell  <c32>  tcell  <c21>) 

(cell  <c32>  tname  32  tcell  <c31>  tcell  <c22>  tcell  <c33>) 

(cell  <c33>  tname  33  tcell  <c32>  tcell  <c23>) 

(tile  <t0>  tname  0)  (tile  <tl>  tname  1)  (tile  <t2>  tname  2) 
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(tile  <t3>  tname  3) 
(tile  <t6>  tname  6) 


(tile  < t4>  tname  4) 
(tile  <t7>  tname  7) 


(tile  <t5>  tname  5) 
(tile  <t8>  tname  8)) 


The  desired  state  is  augmented  with  tbetter  higher,  so  that  evaluations  with  higher  values  will  be  translated 
into  better-preferences  by  eval*prefer-higher-evaluation.  Notice  that  the  bindings  of  the  desired  state  share 
the  same  cell  and  tile  structure  as  the  initial  state.  This  allows  the  goal  test  to  check  only  the  equality  of  these 
augmentations  and  not  the  equality  of  the  names  of  the  cells  and  the  tiles.  This  improves  the  generality  of 
chunking,  but  it  is  not  always  possible,  especially  when  the  desired  and  initial  states  are  created  at  different 
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8.7.  Monitoring  States 

Monitoring  of  states  makes  traces  much  easier  to  read  and  does  not  impact  chunking  when  done  with  no 
changes  to  working  memory.  However  it  may  require  productions  that  are  costly  to  match  because  the 
complete  structure  of  the  state  must  he  matched.  Another  option  is  to  use  the  function  trace-attributes  which 
enables  automatic  tracing  (see  below  and  Section  10.4.1).  Here  is  a  monitor  production  for  the  Bight  Puzzle 
that  will  trace  a  state  after  it  is  generated  but  before  it  is  selected.  Tabstop  binds  its  argument  (<tab>)  to  the 
current  tabstop.  By  using  tabto  with  the  current  tabstop  in  a  write  statement,  the  monitoring  will  line  up  with 
the  trace.  Writc2  is  used  in  the  first  write  command  because  it  does  not  insert  blanks  between  the  atoms  it 
prints. 

( sp  eight*monitor 

(gc  <g>  tproblem-space  <P>  tstate  <s>  toperator  <o>) 

(problem-space  <p>  tname  eight-puzzle) 

(preference  <n>  trole  state  tvalue  acceptable 

tprobl em-space  <p>  tstate  <s>  toperator  {  <>  nil  <o>  }) 
(operator  <o>  tcell  <name>) 

(state  <n>  tbinding  <xll>  <xl2>  <xl3>  <x21>  <x22>  <x23> 

<x31>  <x32>  <x33> ) 

(binding  <xll>  tcell  <cll>  ttile  < o 1 1 > ) 

(cell  <cll>  tname  11)  (tile  <oll>  tname  <vll>) 

(binding  <xl2>  tcell  <cl2>  ttile  <ol2>) 

(cell  <cl2>  tname  12)  (tile  <ol2>  tname  <vl2>) 

(binding  <xl3>  tcell  <cl3>  ttile  <ol3>) 

(cell  <cl3>  tname  13)  (tile  <ol3>  tname  <vl3>) 

(binding  <x21>  tcell  <c21>  ttile  <o21>) 

(cell  <c21>  tname  21)  (tile  <o21>  tname  <v21>) 

(binding  <x22>  tcell  <c22>  ttile  <o22>) 

(cell  <c22>  tname  22)  (tile  <o22>  tname  <v22>) 

(binding  <x23>  tcell  <c23>  ttile  <o23>) 

(cell  <c23>  tname  23)  (tile  <o23>  tname  <v23>) 

(binding  <x31>  tcell  <c31>  ttile  <o31>) 

(cell  <c31>  tname  31)  (tile  <o31>  tname  <v31>) 

(binding  <x32>  tcell  <c32>  t tile  <o32>) 

(cell  <c32>  tname  32)  (tile  <o32>  tname  <v32>) 

(binding  <x33>  tcell  <c33>  ttile  <o33>) 

(cell  <c33>  tname  33)  (tile  <o33>  tname  <v33>) 

--> 

(tabstop  <tab>) 

(write2  (crlf)  (tabto  <tab>)  <name>  "("  <s>  ”)  -->  ”  <n>  (crlf)) 


(writel  (tabto  <tab>)  "  - ”  (crlf)) 

(writel  (tabto  <tab>)  "  | "  <vll>  "I"  <v21>  "|"  <v31>  "|"  (crlf)) 
(writel  (tabto  <tab>)  ”  j  —  |  —  (  —  |"  (crlf)) 

(writel  (tabto  <tab>)  "  |"  <vl2>  <v22>  "  |  "  ^v32>  "I”  (crlf)) 

(writel  (tabto  <tab>)  "  j — | — | — | "  (crlf)) 

(writel  (tabto  <tab>)  "  |"  <vl3>  "|"  <v23>  "|"  <v33>  "|"  (crlf)) 
(writel  (tabto  <tab>)  "  - "  (crlf))) 
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8.8.  Set-up 

Once  all  the  productions  and  the  representations  have  been  defined,  a  few  house-keeping  operations  need 
to  be  performed.  These  should  be  included  at  the  beginning  of  the  file  that  contains  the  productions  that 
define  the  task. 

8.8.1.  Multi-attributes 

To  improve  the  ordering  of  productions,  the  function  multi-attributes  is  ealled  with  a  list  of  those  classes 
that  have  attributes  with  more  than  one  occurrence  per  object  and.  if  known,  the  number  of  occurrences.  In 
this  implementation  of  the  Right  Puzzle,  states  and  desired  states  have  multiple  bindings,  and  cells  have  links 
to  other  cells. 

(mul t i -attributes  '({state  binding  9)  (desired  binding  9) 

(cell  cell  4))) 

8.8.2.  Trace-attributes 

The  user  can  improve  the  readability  of  a  trace  by  providing  a  list  of  attributes  to  be  traced  for  different 
classes.  In  the  Right  Puzzle,  the  operators  do  not  have  distinguishing  names,  so  the  only  way  to  obtain  a 
meaningful  trace  of  the  problem  solving  is  to  include  the  cell  of  the  operator  in  trace-attributes.  The  cell  of 

the  operator  contains  the  position  of  the  tile  that  is  moved  into  the  blank. 

(trace-attributes  '((operator  tile-cell))) 

8.9.  Search  Control 

Besides  defining  the  task  (the  goal  and  the  problem  space),  additional  search  control  can  be  introduced  to 
make  problem  solving  more  efficient. 

8.9.1.  Simple  Search  Control 

Eight*worst-undo  creates  a  worst-preference  for  the  inverse  of  the  operator  that  created  the  current  state. 
This  type  of  search  control  is  common  and  many  tasks  will  have  productions  similar  to  this  one.  The  key  pan 
of  the  production  is  the  determination  of  the  inverse  of  an  operator.  In  the  Right  Puzzle,  the  inverse  of  the 
prior  operator  is  determined  by  finding  the  operator  that  will  move  the  tile  that  was  moved  by  the  prior 
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( sp  eight*worst-undo 

(gc  <g>  tproblem-space  <p>  tstate  <s>) 
(problem-space  <p>  tname  eight-puzzle) 

(state  <s>  tmoved-ti le-binding  <mtb>) 

(binding  <mtb>  tcell  <cmtb>) 

(preference  <o>  trole  operator  tvalue  acceptable 
tproblem-space  <p>  tstate  <s>) 

(operator  <o>  ttile-cell  <cmtb>) 

--> 

(preference  <o>  trole  operator  tvalue  worst 

tgoal  <g>  tproblem-space  <p>  tstate  <s>)) 


8.9.2.  Using  State  Evaluations 

State  evaluations  are  a  standard  way  ot‘  controlling  search.  A  production  that  computes  the  evaluation 
should  look  like  the  following.  (Fvervthing  in  bold  should  be  left  alone.  Everything  in  regular  font  should  be 

replaced  for  the  specific  task.) 

( sp  production-name 

(gc  <g>  tprob lem-space  <p>  tstate  {  <>  <ss>  <s>  } 
tsuperoperator  <so>) 

(problem- space  <p>  tname  task-problem-space-name) 

(operator  <so>  tname  aval uate-ob ject  tevaluation  <e> 
tsuperstate  <ss>  tdesired  <d>) 

:  Conditions  that  compute  the  evaluation  based  on  state  <s>  and 
;  desired  state  <d>.  <d>  will  point  to  the  desired  state 
;  defined  at  the  beginning  of  the  task  and  attached  to  the 
;  desired  and  desired  roles  of  the  top  goal. 

--> 

(evaluation  <e>  tnumeric-value  your-evaluation) ) 

The  default  productions  take  care  of  the  rest,  testing  the  supergoal  and  comparing  the  evaluations  (if  <d>  is 
augmented  with  tbetter  higher/lower).  A  complete  evaluation  production  for  Eight  Puzzle  is  below.  It  gives 
an  evaluation  of  1  if  the  operator  that  created  the  state  moved  a  tile  into  its  desired  position.  A  second 
production  gives  an  evaluation  of  -1  if  a  tile  is  moved  out  of  position,  and  a  third  production  gives  an 

evaluation  of  0,  if  neither  of  these  occur. 

(sp  e  ight*eval -state-p 1 us-one 

(gc  <g>  f problem-space  <p>  estate  {  <>  <ss>  <s>  } 
tsuperoperator  <so>) 

(problem-space  <p>  tname  eight-puzzle) 

(operator  <so>  tname  evaluate-object  tevaluation  <e> 
tsuperstate  <ss>  tpesired  <d>) 

(state  <s>  tmoved- t i 1 e -b i nd i ng  <bl>) 

(binding  <bl>  tcell  <cl>  ttile  <vl>) 

(desired  <d>  tbinding  <b2>) 

(binding  <b2>  tcell  <cl>  ttile  <vl>) 

--> 

(evaluation  <e>  tnumeric-value  l)) 


•'i'\i'\i<i  ;s; 
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8.10.  Example  Trace 

After  loading  all  of  the  Hight  Puzzle  productions  into  Soar,  it  is  ready  to  run.  Relow  is  a  trace  of  the 
problem  solving  and  learning  tor  the  I  'ight  Puzzle.  All  output  is  shown  in  boldface.  (The  trace  of  the  initial 
and  desired  states  at  the  beginning  was  not  produced  b\  the  program.)  Ml  comments  are  prefaced  by  a 

semi-colon  (:). 

(soarload  eight. soar) 

(learn  on  full-trace) 

(d  12) 

learn  status:  on  always  print  full-trace 
0  g:  gOOOl 

initial  state  desired  state 


8  |  3 


6  |  4 

—  I  — 

I  & 


1  p:  p0004  eight-puzzle 

2  s:  S0005 

3  =->g:  g0002  (tie  operator  undecided) 

4  p:  p0051  selection 

5  s:  S0053 

6  o:  o0056  evaluate-ob ject(move-ti le( 13) ) 

7  ==>g:  g0045  (no-change  operator  evaluate-ob ject(move-ti le( 13) ) ) 

8  p:  p0004  eight-puzzle 

9  s:  s0005 

10  o:  o0042  move- t i I e( 13 ) 


8  |  3 


6  |  4 


7  |  5 


11  s:  s0058 

;  An  evaluation  of  - 1  is  created  for  s()058  because  the  7  was 
;  moved  out  of  its  desired  position.  I  his  evaluation  leads  to 
;  the  termination  of  goal  g(X)45  and  will  be  followed  by  the 
:  evaluation  of  another  eight-puzzle  operator. 

:  Since  learning  is  on.  a  chunk  will  be  built.  Rclow  is  a  trace  of 
;  the  production  being  built.  This  trace  is  produced  because  of 
;  full-trace  learning. 
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backtracing  to  determine  conditions 
working-memory  elements  that  will  become  actions: 
(evaluation  e0057  tnumer ic-val ue  -1) 
productions  and  conditions  traced  through: 
eight'eval -state -minus-one 
dec  is  ion -procedure 

eval • select -role -opera tor 

(gc  g0002  toperator  o0056) 

(operator  o0056  tname  evaluate-object) 

(operator  o0056  trole  operator) 

decision-procedure 

(operator  o0056  tobject  o0042) 

(operator  o0056  tsuperprobl em-space  p 0 0 0 4 ) 
(operator  o0056  tsuperstate  $0005) 

(operator  o0056  tdesired  d0003) 

(problem-space  p0004  tname  eight-puzzle) 
decision-procedure 

eight-create-new-state 
dec i s ion -procedure 
dec i s ion -procedure 
(state  s0005  tblank-binding  b 0 0 2 5 ) 

(operator  o0042  ttile-cell  C0020) 

(operator  o0042  tname  move-tile) 

(state  s0005  tbinding  b0019) 

(binding  b0019  tcell  c 0 0 2 0 ) 

(state  s0005  tbinding  bOO 25 ) 

(binding  b0025  tcell  c0026) 

(binding  b0025  ttile  1 0 0 0 6 ) 

(binding  b0019  ttile  t0013) 

(cell  c0020  tcell  c0026) 

(desired  d0003  tbinding  d0035) 

(binding  d0035  tcell  c0020) 

(binding  d0035  ttile  t0013) 

(operator  o0056  revaluation  e0057) 
conditions  that  are  tersed  out:  (binding  <bl>  ttile  <t2>) 

build:p0086 

12  o:  o0054  eval uate-ob ject(move- t i le( 22 ) ) 

•••break*** 

(last-chunk) 

:  Print  out  the  production  that  was  just  built. 


( sp  p0086 

(gc  <gl>  toperator  <ol>) 

(operator  <ol>  trole  operator  tname  evaluate  object 

tsuperprob 1 em-space  <pl>  tobject  <ol>  tsuperstate  <sl> 
tdesired  <d2>  revaluation  <el>) 

(problem-space  <pl>  tname  eight-puzzle) 

(state  <sl>  tblank-binding  <bl>  tbinding  <b2> 
tbinding  {  <>  <b2>  -bl>  }) 

(operator  <ot>  tname  move-tile  ttile-cell  <cl>) 

(cell  <  c  N  tcell  '  c2  > ) 

(binding  <b2>  tcell  <cl>  ttile  <tl>) 

(binding  <bl>  tcell  < c 2 > ) 

(desired  <d2>  tbinding  <dl>) 
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(binding  < d 1 >  ttile  < 1 1 >  tcell  <cl>) 

--> 

(evaluation  <el>  tnumer ic- val ue  -1)) 
n  i  1 

(learn  trace) 

learn  status:  on  always  print  trace  t 
:  Disable  the  trace  ol‘ the  production  construction. 

(run  7  d) 

13  =  =  >g:  g0046  (no-change  operator  evaluate-object(move-t  i  le(22) ) ) 

14  p:  p0004  eight-puzzle 

15  s:  S0005 

16  o:  o0044  move-t i le( 22  ) 


2  |  8  |  3 

-I  — 

l  |  |  4 

7  |  6  |  5 


17  s:  S0065 
build:p0087 

;  I  his  has  an  evaluation  of  1  because  the  6  was  moved  into 
;  us  desired  cell. 

18  o:  o0055  eva 1 uate-ob ject(move- t i 1 e( 33 ) ) 
18:42  p0086 

;  I  he  chunk  built  for  the  first  subgoal  applies  and  computes  an 
;  evaluation  of  - 1  because  the  5  tile  will  be  moved  out  of  its  desired 
;  cell  by  operator  o0043. 

;  Once  all  the  evaluations  arc  computed,  preferences  arc  created 
;  that  compare  the  different  operators  based  on  their  evaluations. 

;  I  wo  of  the  evaluations  arc  the  same,  so  indifferent  preferences 
:  arc  created  between  operators  o<)043  and  o0042.  Noth  of  these 
;  arc  worse  than  o0044.  so  worse-preferences  arc  also  created. 

:  These  preferences  arc  the  results  of  g(X)02,  the  goal  with  the 
;  tie  impasse. 

:  Since  the  problem  solving  to  create  the  two  worse-preferences 
;  was  identical,  two  identical  chunks  could  have  been  built. 

;  The  duplication  is  detected  (although  it  is  not  always  detected) 

:  and  only  one  production  is  built.  Duplicate  chunks  arc  also  built 
;  because  of  the  symmetry  in  the  productions  that  create  the 
:  indifferent-preferences. 

:  I  hc  productions  arc  refracted  so  that  they  do  not  fire 
;  on  the  data  that  was  used  to  create  them. 

dupl  icate  chunk 
build: p0088 
dupl icate  chunk 
build: p0090 

19  o:  O0044  move- 1 i 1 e( 22  ) 

•••break*** 
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(last -chunk) 


(sp  p0090 

(gc  <gl>  tpesired  <d3>  tstate  <sl>  tprobletn-space  <pl>) 
(problem-space  <pl>  tname  eight-puzzle) 

(state  <sl>  tblank-binding  <b2>  tbinding  <b2> 

tbinding  {  <>  <b2>  <bl>  }  tbinding  {  <>  <bl>  <>  <b2>  <b3>  }) 
(binding  <b2>  tcell  <c3>) 

(binding  <bl>  tcell  {  <>  <c3>  <cl>  >  Uile  <t2>) 

(cell  <cl>  tcell  <c3>) 

(desired  <d3>  tbinding  <dl>  tbinding  {  <>  <dl>  <d2>  }) 

(binding  <dl>  tcell  <cl>  ttile  <  1 2  > ) 

(binding  <b3>  tcell  {  <>  <cl>  <>  <c3>  <c2>  } 
ttile  {  <>  <t2>  < t3>  }) 

(cell  <c2>  tcell  <c3>) 

(binding  <d2>  tcell  <c2>  ttile  <t3>) 

(preference  <o2>  trole  operator  tvalue  acceptable 
tgoal  <gl>  tproblem-space  <pl>  tstate  <sl>) 

(operator  <o2>  tname  move-tile  ttile-cell  <c2>) 

(preference  <ol>  trole  operator  tvalue  acceptable 
tgoal  <gl>  tproblem-space  <pl>  tstate  <sl>) 

(operator  <ol>  tcell  <cl>) 

--> 

(preference  <o2>  trole  operator  tvalue  indifferent  treference  <ol> 
tgoal  <gl>  tproblem-space  <pi>  tstate  <sl>)) 
nil 

75: ( run) 


20  s:  S0078 


2  18  13 


1  I  I  4 


7  16  15 


21:48  p0090 
21:48  p0090 

;  Chunk  p0090  detects  that  moving  the  4  and  moving  the  6 
;  are  indifferent  because  they  both  move  a  tile  out  of  its 
;  desired  cell.  This  does  not  determine  the  next  operator 
;  so  a  tie  impasse  is  created. 

21  ==>g :  gOC47  (tie  operator  undecided) 

22  p:  p0085  selection 

This  continues  until  the  problem  is  solved. 
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9.  Advanced  Topics 


9.1 .  Operator  Implementation  Goal  Tests 

If  an  operator  requires  a  subgoal  to  implement  it  and  some  test  exists  to  determine  if  a  state  is  a  valid  result, 
recent  work  suggests  unusual  wav  to  structure  the  subgoal.  The  advantage  of  this  scheme  is  that  even  if 
over-general  chunks  are  learned,  they  will  not  screw  things  up.  The  disadvantage  is  that  the  chunks  will  often 
return  multiple  states.  In  the  subgoal  for  implementing  the  operator  (call  it  Opl),  there  should  be  a 
production  (call  it  detect-candidate)  that  detects  that  a  state  is  a  candidate  result.  A  candidate  result  is  a  state 
that  might  be  a  valid  result  of  the  subgoal  although  the  final  test  has  not  been  made.  It  is  possible  that  all 
states  in  the  subgoal  are  candidate  results.  It  is  also  possible  that  the  candidate  result  is  not  a  state  in  the 
subgoal,  but  only  a  subobject  (or  whatever).  The  action  of  detect-candidate  is  to  augment  the  superstate  (the 
superstate  is  the  state  that  Opl  is  being  applied  to)  with  an  object  of  class  result.  The  result  will  be  augmented 

with  the  operator  (Opl)  and  the  candidate  result.  For  example,  detect-candidate  might  be: 

(sp  detect-candidate 
(gc  <g>  tproblem-space  <p>  tstate  <s> 

rsupergoal  <sg>  tsuperoperator  <so>) 

(problem- space  <p>  tname  implement-op 1 ) 

(state  <s>  tcandidate  yes)  :some  test  that  it  is  a  candidate 
(operator  <so>  tname  opl) 

(gc  <sg>  tstate  <ss>) 

--> 

(state  <ss>  tresult  <r>) 

(result  <r>  toperator  <so>  tcandidate  <s>)) 

In  most  Soar  programs,  this  production  would  have  just  created  the  preference  for  the  state  in  the 
supercontext  and  the  subgoal  would  terminate.  In  this  scheme,  a  second  production,  call  it 
detect-opl-success,  will  create  the  preference.  ITiis  preference  will  fire  outside  the  subgoal  so  that  it  will  not 

be  included  in  the  chunk.  For  example: 

($p  detect-opl-success 

(gc  <g>  tproblem-space  <p>  tstate  <s>  toperator  <o>) 

(problem-space  <p>  tname  xvzzy) 

(state  <s>  tresult  <r>) 

(operator  <o>  tname  opl) 

(result  <r>  toperator  <o>  tcandidate  <c>)) 

(state  <c>  tattribute  value)  :some  test  that  it  is  a  valid  state 
--> 

(preference  <c>  trole  state  tvalue  acceptable 

tgoal  <g>  tproblem-space  <p>  tstate  <s>  toperator  <o>)) 

This  production  will  fire  whenever  a  candidate  has  been  suggested  that  passes  the  final  test.  When  chunking 

is  used,  the  chunk  will  have  as  its  actions  all  states  that  were  candidates  (but  no  preferences). 

Detect-opl-success  will  select  out  the  correct  result  and  create  a  preference.  If  the  chunk  applies  incorrectly. 

detect-opl-success  will  not  fire  and  the  subgoal  will  be  used. 
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9.2.  Operator  Parallelism 

The  parallel-preference  allows  the  user  to  specify  that  two  or  more  operators  can  be  performed  in  parallel. 
In  the  decision  procedure,  if  the  result  is  a  set  of  operators  that  are  mutually  parallel  (there  exist  parallel 
preferences  between  them),  the  current  goal-context-info  for  the  operator  role  is  removed;  and  new  operator 
goal-context-infos  are  created  for  each  of  the  parallel  operators.  Whenever  a  parallel  operator  is  rejected,  its 
goal-context-info  is  removed  from  working  memory.  The  parallel  structure  is  maintained  until  a  new 
preference  causes  a  change  in  a  higher-order  object  or  ail  but  one  of  the  parallel  operators  is  rejected.  Kach 
parallel  operator  is  independent  and  each  can  cause  productions  to  fire  independently  of  the  others.  If  a 
parallel  operator  does  not  lead  to  the  creation  of  a  preference  that  will  change  the  context,  a  no-change 
impasse  will  arise.  To  distinguish  the  subgoals,  each  has  a  tsuperoperator  augmentation  that  contains  the 
identifier  of  one  of  the  parallel  operators.  When  the  operators  have  subgoals,  they  will  run  in  parallel.  These 
subgoals  can  also  have  parallel  operators,  giving  rise  to  exponential  blowups  in  the  number  of  subgoals  being 
pursued  (making  the  goal-contcxt-stack  really  a  tree).  Ihc  parallelism  is  only  simulated  in  the  present 
implementation.  All  of  the  parallel  operator  subgoals  are  synchronized  on  the  decision  cycle.  1  he  function 
pgs  will  print  the  parallel  structure  and  make  a  little  more  sense  of  it  than  the  trace  (see  Section  10.5.2). 

I  his  simple  parallel  structure  gives  AND.  OR  and  hybrid  AND-OR  parallelism.  If  all  of  the  operators  are 
non-monotomc  (they  all  create  new  states),  we  have  OR  parallelism  where  all  of  the  parallel  operators  are 
racing  to  succeed  first.  If  two  (or  more)  parallel  operators  finish  on  the  same  decision  cycle,  there  will  be  two 
(or  more)  acceptable-preferences  for  the  states,  and  this  will  lead  to  a  tie  impasse  if  no  other  preferences  are 
added.  F  ventually  one  of  these  willed  be  picked  after  going  into  the  selection  problem  space  . 

If  all  of  the  operators  are  monotonic  and  just  add  information  to  the  current  state  until  enough  information 
is  available  to  make  a  new  decision,  we  have  AND  parallelism.  A  good  example  of  this  is  when  parallelism  is 
applied  to  the  evaluate-object  operators  in  the  selection  problem  space  (see  Section  6.3).  In  parallel,  all 
objects  will  be  evaluated  until  enough  evaluations  and  preferences  are  created  to  break  the  tie  that  created  the 
selection  subgoal.  If  there  is  a  combination  of  monoionic  and  non-monotomc  operators,  we  get  a  hybrid 
AND-OR  parallelism,  where  the  monotonic  operators  augment  the  current  state  until  a  non  monotonic 
operator  terminates. 

Since  all  parallel  operators  are  running  in  the  same  working  memory  it  is  possible  for  them  to  share 
information  and  to  communicate  partial  results.  One  way  to  achieve  this  is  to  have  the  operators  attach  partial 
results  to  the  state  they  are  applying  to  and  examine  the  state  for  information  created  by  other  operators. 
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10.  Top-level  Variables  and  Functions 

This  chapter  consists  of  the  global  variables,  properties,  and  functions  that  are  used  to  control  Soar  Some 
of  these  are  Ops5  commands  that  have  been  modified  to  provide  more  functionality.  The  Backup  feature  of 
Ops5  does  not  work  in  Soar( but  see  pop-goal  for  a  reasonable  alternative).  The  functions  names  are  followed 
by  a  list  of  their  arguments.  Arguments  in  square  brackets  <Q)  are  optional.  An  argument  ending  in  *  signifies 
that  any  number  of  arguments  may  follows 

10.1 .  Global  Variables 

The  following  global  variables  are  used  to  control  certain  aspects  of  Soar.  Many  of  these  are  also  referred  to 
in  sections  on  functions  that  they  affect.  AH  global  variables  in  Soar  begin  and  end  with  an  asterisk  <*). 

*chunk-all-paths*  If  T,  then  when  the  exact  same  subgoal  result  is  produced  by  two  or  more 

production  firings,  chunks  will  be  built  based  on  each  of  the  production 
firings.  *Chunk-all-paths*  is  initially  nil. 

•chunk-classes*  A  list  of  SP  class  names  for  which  at  least  one  must  occur  in  the  conditions 

of  a  chunk  for  it  to  be  built.  This  helps  eliminate  chunks  that  are  overly 
general.  *Chunk-classes*  is  initially  (problem-space  state  operator). 

*chunk-free-problem-spaces*  A  list  of  problem-space  names  for  which  chunking  should  not  be  used.  If 

the  current  problem  space  in  a  subgoal  has  its  name  in  the  list,  and  the 
subgoal  is  terminated,  no  chunk  will  be  built  for  that  subgoal. 

•chunks*  A  list  of  the  names  of  all  of  the  productions  that  have  been  learned. 

•max-chunk-conditions*  No  production  will  be  built  that  has  a  greater  number  of  conditions  than 

•max-chunk-conditions*.  *Max-chunk-conditions*  is  initially  200. 

•max-elaborations*  If  the  elaboration  phase  runs  more  that  *max-elaborations*  then  the 

elaboration  phase  is  terminated  and  the  decision  procedure  is  executed. 
The  default  value  of  *max-elaborations*  is  100. 

•max-recurse*  The  maximum  recursive  depth  that  the  ordering  algorithm  will  use  in 

breaking  ties  between  competing  conditions.  By  increasing  the  depth,  the 
ordered  productions  can  sometimes  be  more  efficient,  although  loading  in 
the  productions  will  take  longer.  *Max-recurse*  is  imuallv  2. 

*sp-classes*  A  list  of  dotted  pairs  w  here  the  first  element  of  each  dotted  pair  is  the  SP 

class  name  and  the  second  element  is  the  P  class  name.  When  translating 
from  SP  format.  .Soar  uses  *sp- classes*  to  replace  SP  classes  with  P  classes. 
I’sers  should  not  have  to  add  pairs  to  *sp-classes*.  »inee  this  is  done 
automatically  by  Soar  I  he  first  time  a  SP  class  is  encountered,  iu  along 
with  its  name  concatenated  with  -info  is  added  to  *sp-classes*.  I  he  user 
should  add  pairs  to  *sp-elasscs*  if  he  wants  to  have  more  than  one  SP  class 
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translated  into  the  same  P  class  (gc.  goal-context,  context,  and  goal  all 
translate  into  goal-context-info). 

*spo-default-depth*  The  default  depth  of  objects  that  spo  prints  out.  The  value  of 

*spo-default-depth*  is  initially  1. 

*subgoal-tabs*  If  T.  watch  and  pgs  will  indent  during  the  tracing  or  printing  of  the 

context  stack.  If  nil.  watch  and  pgs  will  not  indent,  but  instead  will  print 
the  subgoal  depth  as  a  number.  The  value  of  *subgoal-tabs*  is  initially  T. 

•warning*  If  T.  warnings  are  printed.  If  nil.  warnings  are  not  printed.  The  value  of 

♦w-arning*  is  initially  T. 

*watch-free-problem-spaces*  Contains  a  list  of  problem-space  names  that  will  not  be  traced  with  watch 

0.  The  value  of  *watch-free- problem-spaces*  is  initially  nil. 


10.2.  Initialization 

10.2.1 .  Init-soar 

While  running  Soar,  the  user  may  wish  to  empty  working  memory  and  restart  a  run  using  the  same  core 
image.  The  function  init-soar  empties  working  memory.  It  should  be  called  whenever  the  user  wishes  to 
restart  without  reloading  productions.  After  it  has  been  called,  new  productions  can  be  added,  either 
manually  or  by  reading  a  file.  Old  productions  (including  chunks),  that  haven't  been  replaced,  will  still  be 

available. 

( init-soar) 


10.2.2.  Restart-soar 

While  running  Soar,  the  user  may  wish  to  replace  all  of  the  productions,  but  still  maintain  the  same  Lisp 
core  image,  rhe  restart-soar  function  is  a  Soar  function  that  re-imtializes  the  system,  removes  all  productions. 

including  chunks,  empties  working  memory  and  resets  all  global  variables  to  their  initial  (default)  values. 

(  restart-soar) 


10.2.3.  Init-context  idl  id2  id3 

The  init-context  function  first  calls  init-soar  to  clear  working  memory,  and  then  creates  the  context  in 
working  memory.  If  it  is  not  called,  the  initial  context,  except  for  the  goal,  is  all  undecided:  (gc  gOOOl 
tproblem-space  undecided  tstate  undecided  toperator  undecided).  There  are  three  arguments.  The  first  is  the 
identifier  of  the  initial  problem-space,  the  second  is  the  identifier  of  the  initial  state  and  the  third  is  the 

identifier  of  the  initial  operator.  The  function  gensyms  a  goal  identifier,  which  is  returned  as  the  result, 
(init-context  ’ prob lem-space 1  'statel  '  do-e ight-puzzl e ) 
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10.3.  Loading,  Running,  and  Breaking 

10.3.1.  Soarload  file 

The  soarload  function  will  load  in  file  file,  it  must  be  used  in  place  of  load  on  Xerox  D-machincs  for  files 

containing  productions,  but  its  use  is  optional  for  all  other  implementations  of  Soar. 

(soarload  'eight. soar) 

10.3.2.  Multi-attributes  L 

The  multi-attributes  function  takes  a  list  of  two-  or  three-clement  lists  as  its  argument.  I  he  first  element  of 
each  sublist  is  a  SP  class  name,  the  second  element  is  a  SP  attribute  (not  an  Ops5  attribute,  but  the  attributes 
that  show  up  in  SP  format),  and  the  third  (optional)  clement  is  a  number.  Ihc  function  declares  that  the 
attribute  for  the  SP  class  will  appear  multiple  times  for  a  given  object.  This  usually  happens  when  an  object 
has  a  set  of  subobjects.  I  hc  third  argument  is  the  expected  number  of  occurrences  of  the  attribute  tor  a  given 
object  of  that  class.  I  hc  default  is  5.  When  this  information  is  provided,  the  ordering  algorithm  can  produce 
more  efficient  P  format  productions  and  greatly  speed  up  the  execution  of  a  system 

10.3.3.  Run  /V[D] 

The  run  function  executes  the  production  system  with  the  current  working  memory  for  the  number  of 
cycles  given  by  N.  If  D  is  missing.  /V  gives  the  number  of  production  cycles  to  be  executed.  In  Soar,  during 
the  elaboration  phase,  many  productions  may  fire  in  parallel  on  the  same  production  cycle.  This  is  one 
production  cycle.  However,  the  elaboration  phase  may  last  many  production  cycles,  and  each  cycle  is  counted 
toward  the  total.  Each  decision  phase  is  also  counted  as  one  production  cycle.  If  D  is  d  (no  other  values  are 
legal),  then  /V  is  the  number  of  decision  cycles  that  are  executed  before  halting.  In  this  case  Soar  halts  just 
after  the  decision  procedure  of  the  /Vth  decision  cycle.  If  A'  is  an  object  identifier  or  object  name.  Soar  halts 
when  an  object  with  that  identifier  or  name  is  selected  as  the  current  value  of  a  role  in  a  context.  If  ,V  is  a 
SP-form  working-memory  element.  Soar  halts  when  that  working-memory  element  is  created.  If  a  run  is  done 
following  init-soar.  it  automatically  initializes  working  memory  with  all  non-goal  roles  in  a  goal-context  being 

undecided. 

(run  100  d) 

10.3.4.  D  N 

(1)A)  is  equivalent  to  (Run  N  D). 
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10.3.5.  Pbreak  L 

Pbreak  allows  the  user  to  give  a  set  of  names  of  productions,  and  break  on  the  production  cycle  after  they 
fire.  It  has  been  expanded  in  Soar  to  allow  the  user  to  break  after  an  object  with  a  specific  name  is  selected 
for  a  context  role.  L  can  either  be  the  name  of  a  production  to  break  after,  or  it  can  be  a  name  or  identifier  of 
the  object  the  user  wishes  to  break  on.  Soar  will  break  following  the  decision  procedure  when  an  object  with 

that  name  or  identifier  is  selected  as  current.  If  /.  is  nil.  all  break  points  are  listed. 

(pbreak  selection  evaluate-object ) 

(pbreak  initial ize-rl-problem-space  reject-worse) 

10.3.6.  Unpbreak  JL* 

(Jnpbreak  removes  breaks  set  by  pbreak.  To  remove  a  break,  use  the  same  argument  in  unpbreak  as  was 

used  in  pbreak.  If  /  is  nil.  all  breaks  are  removed. 

( unpbreak  nil) 

(unpbreak  initial ize-rl-problem-space  reject-worse) 

10.3.7.  User-select  X 

If  X  is  T,  then  whenever  Soar  is  going  to  make  a  choice  between  indifferent  objects,  the  user  will  be  asked 
to  make  the  selection.  If  X  is  nil.  Soar  will  make  the  selection  randomly.  If  X  is  'first.  Soar  will  always  select 
the  first  one  found.  This  is  a  deterministic  selection.  If  X  is  a  list,  then  the  list  should  contain  numbers  or 
atoms.  For  each  selection,  the  first  element  of  the  list  is  stripped  off  and  used  to  select  an  object.  If  it  is  a 
number,  it  will  be  used  to  index  into  the  list  of  objects  to  be  selected  ( 1  for  the  first).  If  the  number  is  less 
than  1.  or  greater  than  the  total  number  of  choices,  the  user  is  asked.  If  it  is  a  symbol,  the  objects  are 
examined,  and  the  first  one  that  has  the  symbol  as  a  name  or  the  value  of  a  trace-attribute  is  selected.  If  the 
symbol  does  not  match  any  of  the  choices,  the  user  is  asked.  When  the  list  is  exhausted,  user-select  is  called 
automatically  with  the  value  of  *default-user-select*.  which  is  initially  T.  The  original  value  for  user-select  is 
'first. 

(user-select  t) 


XI  XOX  P\R<  (Si  -15  JAM  \K v  -Aft 


TOP-LEVKI.  VARIABLES  AM)  FUNCTIONS 


65 


10.4.  Tracing 

10.4.1.  Trace-attributes  L 

Trace-attributes  takes  a  list  of  two-elcmcnt  lists  as  its  argument.  The  first  element  of  each  sublist  should  be 
a  SP  class  and  the  second  clement  should  be  a  SP  attribute.  After  trace-attributes  is  called,  a  watch  trace  of 
level  0-2  (and  PGS)  will  print  out  the  value  of  the  specified  attributes  when  an  object  is  selected  to  a  context 
role.  If  the  value  is  an  identifier  with  a  tname  attribute,  then  the  name  of  the  identifier  is  printed.  ITie 
tracing  is  recursive,  so  that  if  the  value  is  an  identifier  that  appears  in  an  augmentation  with  another  class  in 
trace- attributes,  its  attributes  will  be  traced,  and  so  on.  The  recursion  stops  whenever  a  previously  traced 
identifier,  or  one  that  has  no  trace-attributes,  is  encountered.  I  race-attributes  is  initialized  with  ((goal  role) 
(goal  impasse)  (goal  superoperator)  (operator  instance)  (operator  object)).  The  tname  attribute  is  handled 
specially  for  all  classes,  so  it  should  not  be  included  in  trace-attributes.  All  calls  to  trace-attributes  merely  add 
pairs  to  the  list. 

(trace-attributes  '((state  backplane)  (operator  module)  (module  size)) 


10.4.2.  Watch  N 

As  in  Ops5.  A'  is  a  parameter  that  determines  the  amount  of  trace  information  produced  by  the  system. 

Soarcxpands  the  available  values  and  expands  the  different  levels  of  trace  information. 

-1  No  tracing. 

0  Object  tracing.  Changes  to  a  goal-context  arc  listed.  No  production  or  working 

memory  tracing.  Ifie  object  tracing  includes  the  current  decision  cycle  number,  the 
role  being  changed,  the  identifier  of  the  object,  the  name  and  any  attributes  declared 
with  trace-attributes  (sec  above).  Objects  are  indented  (3  *  the  subgoal  depth). 
Indenting  can  be  turned  off  by  setting  the  global  variable  *subgoal-tabs*  to  nil.  When 
there  is  no  indenting,  the  subgoal  depth  is  printed  at  the  beginning  of  each  line. 
Subgoals  arc  prefaced  by  "  =  =  >"  so  they  are  easy  to  pick  out 

1  ==>g:  gOOOl  (no-change  goal) 

2  p:  p0003  eight-puzzle 

3  s:  sOO  12 

4  ==>g:  g0031  (tie  operator) 

5  p:  p0032  selection 

6  s:  s0033 

7  o:  o0036  evaluate-object(up) 

.5  Same  as  1.  except  no  trace  of  the  time-tags  of  working- memory  elements  that  match 

the  conditions  of  the  productions,  or  arc  created  by  productions  or  arc  auto- removed. 

I  \dds  trace  of  the  productions  that  lire.  In  Soar,  the  trace  starts  with  the  decision  cycle 

number  followed  by  the  production  cycle  number  (the  number  of  production  cycles  — 
where  many  productions  can  tire  in  parallel  on  one  production  cvclc  —  since  the  last 
init-soar).  These  numbers  are  followed  hv  the  name  of  the  production  that  tired. 
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When  the  decision  procedure  is  executed,  the  role  and  the  name  of  the  selected  object 
are  traced.  If  there  is  an  impasse  in  the  decision  procedure,  the  type  of  impasse  and 
the  name  of  the  newly  created  subgoal  is  printed.  Following  this  information  is  a  list 
of  the  data  that  was  matched  by  the  production  (given  by  time-tags)  followed  by  the 
data  that  was  created  by  the  production  (given  by  time-tags).  These  working-memory 
elements  are  Ops5  working-memory  elements  and  will  not  be  in  SP  format  if  printed 
out  directly  using  the  wm  function.  For  example: 

73:174  decide  operator  s0415 
o:  up  1466 

74:175  create-newstate  1443  1456  17  1463  1466  23  -->  1467 
The  first  line  is  a  trace  of  a  decision  occurring  during  the  73rd  decision  cycle.  It  is  the 
174th  production  cycle  and  operator  S0415  (also  called  up)  is  selected.  1466  is  the 
time-tag  of  the  working-memory  element  for  the  current  operator.  On  the  following 
production  cycle,  production  create-newstate  fires  using  the  six  working-memory 
elements  listed  to  create  1467.  On  the  return  from  subgoals,  the  working-memory 
elements  that  were  garbage-collected  arc  listed  following 

1.5  Just  like  1.  except  that  the  actual  working-memory  elements  added  to  and  removed 

from  working  memory  are  printed. 

2  Prints  out  the  time-tags  of  the  working-memory  elements  matched  by  the  conditions 

of  the  production  and  the  actual  working- memory  elements  added  to  and  removed 
from  working  memory. 

Default  =  0. 

Fxample: 

(watch  1) 


10.4.3.  Decide-trace  X 

If  X  is  T,  decide- trace  is  enabled.  If  X  is  nil,  decide-trace  is  disabled.  The  default  is  nil.  When  decide-trace 

is  enabled,  a  trace  of  the  decision  procedure  is  displayed. 

( decide-trace  nil) 


10.4.4.  Ptrace  X* 

If  X  is  a  production  name,  it  will  be  traced  whenever  it  fires.  If  X  is  an  SP-form  working-memory  element 
that  working-memory  element  is  traced  when  it  is  created  or  matched  by  a  firing  production.  If  X  is  an  object 
name  or  identifier,  all  working-memory  elements  that  augment  that  object  arc  traced  when  they  are  created  or 

matched  by  a  firing  production,  fracing  of  chunks  is  also  controlled  by  the  trace  option  of  learn. 

(ptrace  create-new-state ) 
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10.4.5.  Unptrace 

Removes  traces  set  by  ptracc. 

(unptrace) 

10.5.  Displaying  Information 

10.5.1.  cs 

The  cs  function  produces  a  listing  of  the  productions  that  are  in  the  conflict  set.  In  Soar,  these  are  the 

productions  that  will  tire  on  the  next  production  cycle.  If  the  next  cycle  is  an  elaboration  phase,  the 

elaboration  productions  that  will  fire  arc  displayed.  If  the  next  production  cycle  is  a  decision,  the  number  of 

instantiations  of  decision*gather-prcferences  is  displayed.  l)ccision*gather-preferences  matches  all  of  the 

preferences  relevant  to  the  context  stack.  Note:  some  elaboration  productions  may  be  in  the  conflict  set  but 

not  change  working  memory  because  the  elements  they  create  are  already  in  working  memory. 

(cs) 

10.5.2.  PGS 

This  prints  out  the  goal-context  stack,  indented  at  each  subgoal,  followed  by  the  decision  cycle  number.  If 
*subgoal-tahs*  is  nil,  the  indentation  will  be  replaced  by  numbered  depth  counts.  For  parallel  operators,  the 
goal  stack  is  printed  out  depth-first  with  a  space  between  the  end  of  one  parallel  operator's  subgoal  tree  and 
the  beginning  of  the  next  parallel  operator.  This  is  a  great  function  for  finding  out  where  you  are  in  problem 
solving. 

(pgs) 

10.5.3.  SPR  X 

The  spr  function  is  the  generic  SP  printer  for  all  types  of  objects.  It  takes  any  number  of  arguments  which 
can  be  time-tags,  object  identifiers,  partial  descriptions  or  production  names.  It  then  prints  the  associated 

working  memory  elements  or  productions  appropriately.  If  no  argument  is  given,  it  calls  pgs. 

(spr  (operator  tname  eval uate-object ) ) 

10.5.4.  PPWM  X* 

Without  any  arguments,  ppwm  prints  out  all  of  working  memory.  Arguments  to  ppwm  provide  a  partial 
description  of  working-memory  elements  in  P-format:  a  class  and  attribute-value  pairs.  I  hese  arguments  act 
as  a  filter,  so  that  only  those  working-memory  elements  that  match  arc  printed.  In  the  example,  the  second 

call  will  print  out  only  acceptable-preferences  for  goals. 

( ppwm) 

(ppwm  preference  trole  goal  rvalue  acceptable) 


\l  R0\  Pari.  Isl  .5  i  \\t.  \kv  .-.v> 


68 


SOAR  LSI'R'S  MANLAI 


10.5.5.  SPPWM  X* 

The  sppwm  function  is  an  SP  version  of  ppwm.  Its  input  is  a  partial  description  of  an  object  in  SP  format. 

It  finds  all  objects  matching  that  description  and  prints  them  in  SP  format. 

(sppwm  operator  rname  evaluate-object) 

10.5.6.  WM  N 

The  wm  function  takes  any  number  of  time-tags  as  its  argument,  and  prints  out  the  working-memory 
elements  with  those  time-tags.  The  time-tags  of  working-memory  objects  arc  listed  when  they  are  created 

during  watch  1  and  2. 

(wm  45  54) 

10.5.7.  SWM  N 

l'hc  swm  function  takes  any  number  of  time-tags  as  its  argument,  and  prints  out  the  objects  with  the 
identifiers  of  working-memory  elements  with  those  time-tags.  The  time-tags  of  working  memory  objects  arc 

listed  when  they  are  created  during  watch  1  and  2. 

(swm  45  54) 

10.5.8.  PO/ 

The  po  function  will  print  out  the  augmentations  of  the  object  with  identifier  /  (it  only  accepts  one 

argument  at  a  time).  This  will  print  out  preferences  and  augmentations  where  the  object  is  in  the  identifier 

field.  It  will  not  print  out  your  own  weird  data  structures  if  identifier  is  not  in  the  identifier  field. 

(po  S0003 ) 

10.5.9.  SPO  /*  [D] 

The  spo  function  is  an  expanded  SP  version  of  po.  It  prints  out  the  augmentations  of  the  identifiers  in  SP 
format.  It  docs  not  print  out  preferences.  It  has  an  optional  final  argument:  depth.  If  depth  is  given,  spo  will 
print  out  a  depth-first  expansion  of  the  objects  and  subobjects  to  depth  I).  It  will  only  print  the 
augmentauons  of  each  object  once.  Ihe  default  depth  (for  when  no  second  argument  is  provided)  is  held  in 

global  variable  *spo-default-depth*.  which  is  initial! v  1. 

(spo  S0003  2) 
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10.5.10.  SPOP  f’[D] 

The  spop  function  ill  print  out  the  preferences  of  the  identifiers  in  SP  format.  It  does  not  print  out 
augmentations.  It  has  an  optional  final  argument:  I).  If  I)  is  given,  spo  will  print  out  a  depth-first  expansion 
of  the  preferences  of  objects  in  the  context  fields  of  preferences  of  each  object  once.  The  default  depth  (for 

when  no  second  argument  is  provided)  is  held  in  global  variable  *spo-dcfault-depth*  which  is  initially  1. 
(spop  S0003  2) 

10.5.1 1.  PM  P* 

The  pm  function  prints  out  production  /’  in  P  format. 

(pm  e ight*create-new-state) 

10.5.12.  SPM  P 

The  spm  function  prints  out  production  P  in  SP  format. 

(spm  e ight’ereate-new-state ) 

10.5.13.  Matches  P 

The  matches  function  lists  the  time-tags  for  all  of  the  working-memory  elements  that  match  the  conditions 

of  production  P.  It  also  prints  all  of  the  partial  instantiations  of  production  P(with  time-tags). 

(matches  eight*create-new-state) 

10.5.14.  Smatches  P* 

I  he  smatches  function  takes  the  name  of  a  production  as  its  argument  (unquoted).  It  prints  out  the  most 
complete  match  for  the  production  given  the  current  working  memory  (as  lime-tags)  followed  by  a  listing  of 
the  production  with  a  pointer  to  the  condition  where  the  match  failed.  Hach  condition  in  the  production,  is 
prefaced  by  the  number  of  partial  instantiations  active  at  that  point.  This  function  subsumes  most  of  the 

interesting  aspects  of  matches. 

( smatches  eight*create-new-state) 

10.5.1 5.  Back-trace  [/]  [G] 

I’he  back -trace  function  lists  all  the  productions  used  in  goal  G  to  produce  the  working-memory  elements 
described  by  /.  It  also  prints  out  the  working-memory  elements  that  were  matched  by  those  productions  that 
would  be  included  in  a  chunk  if  it  were  to  be  built  with  /  as  its  actions.  If  G  is  not  provided,  the  most  recent 
subgoal  is  used,  /can  be  either  a  time-tag  of  a  working-memory  element,  in  object  identifier  (in  which  ease 
all  augmentations  of  the  object  are  used),  or  a  SP  pattern  that  includes  at  least  one  attribute  (in  which  case  all 
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working-memory  elements  matching  the  SP  pattern  are  used).  If  /  is  not  included,  back-trace  will  use  the 
actions  for  goal  G (if  there  arc  no  actions  at  this  time,  nothing  will  be  printed). 

Beginning  with  the  working-memory  elements  described  by  /.  the  productions  that  created  /  arc  found, 
their  names  are  printed,  and  the  working-memory  elements  that  matched  their  conditions  arc  collected.  If  the 
working-memory  element  was  created  in  a  subgoal,  the  working-memory  elements  that  would  be  used  as 
conditions  for  a  chunk  for  that  subgoal  arc  collected,  and  the  identifier  of  the  subgoal  is  printed.  Printing 
from  then  on  is  indented  until  all  the  collected  working-memory  elements  have  been  processed.  If  a  working- 
memory  element  is  the  same  as  a  working-memory  element  that  has  already  been  processed,  it  is  ignored.  If  a 
collected  working-memory  element  was  created  before  G.  it  is  printed  because  it  will  be  the  basis  of  a 
condition  in  a  chunk  built  for  G.  If  a  collected  working-memory  clement  was  created  by  another  production 
firing  in  the  subgoal,  or  by  a  subgoal,  or  by  the  decision  procedure,  then  the  process  recurscs.  If  a  collected 
working-memory  clement  was  created  by  the  decision  procedure  (cither  a  context  slot  or  a  goal  augmentation) 
decision-procedure  is  printed  and  the  working-memory  clement  associated  with  that  creation  act  is  back- 

traced  (see  Section  7.1  for  more  information). 

(back-trace  o0034) 

(back-trace  (evaluation  e0021  tnumeric-value  -1)  g0032) 

10.5.16.  PI  P[N\ 

[he  pi  function  prints  out  the  working-memory  elements  that  form  the  A/th  partial  instantiation  for 

production  P.  If  N  is  missing,  the  first  partial  instantiation  is  listed. 

(pi  eight*create-new-state) 

10.5.17.  Print-stats 

The  print-stats  fonction  lists  a  summary  of  statistics  for  the  runs  of  Soar  since  start-up  or  the  last  call  to 
init-soar.  Most  of  the  statistics  concern  a  set  of  events,  such  as  production  firings,  decision  cycles,  etc.  Ihe 
total  number  of  each  type  of  event  is  given,  along  with  the  number  of  events  per  second. 

•  Number  of  productions:  The  is  the  total  number  of  productions  in  the  system,  including  all  chunks 
built  during  problem  solving. 

•  N  umber  of  nodes,  with  sharing/without  sharing:  The  first  number  is  the  number  of  nodes  actually 
used  in  the  network.  Ihe  second  number  is  the  number  of  nodes  that  would  be  required  if  there 
were  no  sharing. 

•  Elapsed  time:  On  a  Vax  or  D-machinc.  this  is  CPU  time.  On  the  3600  this  is  elapsed  real-time 
while  running. 

•  Number  of  decision  cycles:  This  is  the  total  number  of  decision  cycles. 
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•  Number  of  production  cycles:  I  “his  is  the  total  number  of  production  cycles  that  were  executed, 
which  include  the  number  of  decision  cycles  and  elaboration  cycles.  I  his  is  not  the  total  numb  r 
of  production  firings,  since  elaborations  fire  in  parallel. 

•  Number  of  elaboration  cycles  per  decision  cycle:  This  is  the  average  number  of  elaboration  Lytles 
executed  during  a  decision  cycle.  Ibis  is  computed  by  computing  the  total  number  ot  elaboration 
cycles  (production  cycles  -  decision  cycles)  and  dividing  by  the  number  of  decision  cycles. 

•  Number  of  production  firings:  This  is  the  total  number  of  productions  that  were  tired,  bach 
decision  cycle  is  counted  as  one  and  only  one  production  firing. 

•  Number  of  elaboration  productions  firing  in  parallel:  I  his  is  computed  by  dividing  the  number  of 
elaboration  production  firings  (total  production  firings  ■  decision  cycles)  by  the  number  of 
elaboration  cycles. 

•  Number  of  actions:  This  is  the  total  number  of  actions.  This  includes  all  additions  and  deletions 
from  working  memory. 

•  Working  memory  size:  This  gives  the  average,  total,  and  current  number  of  working-memory 
elements. 

•  Token  memory  size:  T  his  gives  the  average,  total,  and  current  number  of  tokens  used  to  represent 
the  working-memory  elements  in  the  RKTK  network.  When  this  number  is  large,  the  system 
tends  to  slow  down. 


Below  is  an  example  from  running  the  Hight  Puzzle. 

(print-stats) 

Run  Statistics 

69  Productions  (1034  //  3329  Nodes) 

21  Seconds  Elapsed 

22  Decision  Cycles  (1.047619  per  sec.) 

47  Prod  Cycles  (2.238095  per  sec.) 

(1.136364  E  cycles/  D  cycle) 

112  Prod  Firings  (5.333334  per  sec.) 

(3.6  Elab.  prod,  in  parallel) 

498  RHS  Actions  (23.71429  Per  Sec.) 

191  Mean  working  memory  size  (260  Maximum  222  Current) 
419  Mean  token  memory  size  (651  Maximum  521  Current) 


10.6.  Changing  Working  Memory  and  Production  Memory 


10.6.1.  Make 

I  he  make  function  adds  to  working-memory  the  P-format  working-memory  element  that  follows  it  in  the 
function  call. 

(make  state-info  tidentifier  S4404  ^attribute  name  rvalue  Cleveland) 
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10.6.2.  Smake 


The  smake  function  adds  to  working-memory  the  SP-format  working-memory  elements  that  follow  it  in  the 
function  call. 

(smake  state  S4404  tname  Cleveland) 


10.6.3.  Sremove  n' 

The  sremove  function  removes  from  working  memory  the  element  with  time-tag  N.  This  can  be  used  only 
at  the  top-level  to  remove  working-memory  elements  and  can  not  be  included  in  production  actions.  In  most 
Ops5  implementations,  this  is  just  remove,  however  to  avoid  confusion  with  some  Lisp  commands,  we  call  it 

sremove. 

(sremove  45) 

10.6.4.  Pop-goal  [X*] 

The  pop-goal  function  removes  the  goal  X.  all  its  subgoals,  and  all  working-memory  elements  created  in  it 
or  its  subgoals.  No  chunks  are  created  when  the  goal  is  popped.  If  X  is  not  specified,  the  last  subgoal  created 
is  popped.  It  takes  any  number  of  subgoals  as  arguments,  and  will  pop  all  of  them,  however,  this  is  only 
useful  when  parallelism  is  being  used.  This  function  allows  a  limited  form  of  back  up  in  Soar.  After  pop-goal 
has  been  executed.  Soar  is  in  an  elaboration  phase,  and  unless  the  user  adds  productions  or  working-memory 

elements.  Soar  will  create  a  new  subgoal  in  the  next  decision  that  is  just  like  the  one  that  was  popped 
(pop-goal  g0043 ) 


10.6.5.  P 

The  p  function  creates  a  P  format  production.  If  this  replaces  a  previously  created  production  (same  name. 

different  body)  the  old  production  is  excised  and  the  name  of  the  excised  production  is  printed. 

(p  eight*create-new~state  elaborate 

(goal -context-info  tidentifier  <g>  tattribute  state  rvalue  <s>) 
(goal -context- info  tidentifier  <g>  tattribute  operator 
tvalue  <o>) 

(op-info  tidentifier  <o>  tattribute  name  tvalue  up) 

--> 

(make  state-info  tidentifier  <n>  tattribute  name  tvalue  down)) 


10.6.6.  SP  ... 

The  sp  function  creates  a  SP  format  production.  If  this  replaces  a  previously  created  production  (same 
name,  different  body)  the  old  producuon  is  excised  and  the  name  of  the  excised  producuon  is  printed. 
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(sp  e  ight*create-new-state 

(gc  <g>  tstate  <s>  toperator  <o>) 
(operator  <o)  vname  up) 

--> 

(state  <n>  tname  down)) 


10.6.7.  Excise  P 


The  excise  function  removes  production  /*  from  production  memory.  If  a  production  is  excised,  a  "8"  is 
displayed. 

(excise  e ight*create-new-state ) 

10.7.  Chunking 


10.7.1.  Learn  [A  J 

This  function  is  called  to  modify  or  examine  a  number  of  flags  that  control  chunking.  Hie  arguments  are 
not  evaluated.  If  no  arguments  arc  included,  all  of  the  flags  arc  displayed.  Below  is  the  list  of  argument  pairs, 
the  first  one  (underlined)  is  the  default. 

•  never/on/off 

On  turns  learning  on.  off  turns  learning  off.  Never  turns  learning  off  and  learning  can  not  be  used 
before  init-soar  is  called.  If  learning  is  off.  but  not  never,  it  can  be  turned  on  (and  off)  at  anytime 
during  a  run.  With  never.  Soar  docs  not  maintain  the  extra  information  required  by  the  learning 
mechanism.  Never  runs  about  8%  faster  than  off.  which  runs  about  25%  faster  than  on.  These 
figures  depend  upon  the  complexity  of  the  objects  in  working  memory  and  the  frequency  of 
subgoal  creation  and  termination. 

•  alwavs/hottom-un 

With  always,  productions  arc  built  whenever  a  subgoal  terminates.  With  bottom-up.  productions 
arc  only  built  for  terminal  subgoals  (subgoals  that  do  not  have  any  subgoals). 

•  print/noorint/full-print 

With  print,  production  names  arc  printed  as  they  are  created.  With  noprint,  nothing  is  printed. 

With  full-print,  the  lull  production  is  printed  when  it  is  created. 

•  tracc/untrace/full-trace 

With  trace,  every  time  a  production  is  chunked,  it  is  added  to  a  list.  When  a  production  on  that 
list  tires,  it  is  traced  at  Watch  level  1.  With  full-trace,  the  building  of  the  production  is  also  traced. 

(learn  on  bottom-up  full-print) 
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10.7.2.  Last-chunk 

This  will  print,  in  SP  format,  the  last  production  created  by  the  chunking  mechanism. 

(last-chunk) 

t 

i 

’  10.7.3.  Excise-chunks 

i 

This  will  excise  all  productions  that  have  been  chunked  since  starting  up  Soar  (either  through  starting  Soar 
or  calling  restart-soar).  The  names  of  all  chunked  productions  are  held  in  ’chunks*.  The  function  uses 

♦chunks*  to  remove  the  chunked  productions  and  then  sets  ’chunks*  to  nil. 

1  (excise-chunks) 

i 

10.7.4.  List-chunks 

(  This  will  print  all  productions  with  names  in  ’chunks*  (whenever  a  chunk  is  created,  it  is  automatically 

’  added  to  ’chunks*)  in  SP  format.  The  chunks  are  listed  in  the  order  they  were  created. 

(list-chunks) 


I  RRORS.  WARNINGS  AND  RI  COVI  RY  HINTS 

1 1 .  Errors,  Warnings,  and  Recovery  Hints 

11.1.  Errors 

•  Illegal  production  name:  The  name  of  the  production  was  a  list. 

•  Illegal  production  type:  The  type  of  the  production  was  neither  missing,  nor  elaborate  nor  decide. 

•  No  in  production:  was  not  found  in  the  production.  This  usually  arises  when  there  is  an 

extra  ')’  in  the  condition  elements. 

•  \ttempt  to  negate  a  compound  object:  A  negation  was  placed  before  an  SP  object  that  had  more 
than  one  attribute.  This  will  create  a  separate  working-memory  element  for  each  attribute  which 
is  not  always  the  desired  effect  (see  Section  3.4).  If  that  is  the  desired  effect,  place  a  negation 
before  each  attribute. 

•  Didn't  find  terminator:  A  terminator  (either  »  or  })  to  match  a  previously  encountered  <<  or  { 
was  missing  from  a  condition  of  the  production. 

•  Missing  »:  A  «  is  missing  a  closing  ». 

•  Missing  }:  A  {  is  missing  a  closing  }. 

•  Didn’t  find  a  t  when  expected:  \  -  was  not  followed  by  a  t. 

•  Atomic  conditions  are  not  allowed:  A  condition  must  be  a  list. 

•  Non-numeric  constant  after  numeric  predicate. 

•  Wrong  context  for  J:  A  }  can  occur  only  following  a  j . 

•  Unrecognized  symbol. 

•  Not  a  legal  function  name. 

•  Condition  is  too  long:  The  condition  has  loo  many  fields.  This  should  never  happen. 

•  fab  must  be  a  number:  \  unknown  P-format  field  name  was  encountered. 

1 1 .2.  Warnings 

Miscellaneous 

•  Illegal  multi-attribute  value:  A  multi-attribute  can  only  have  a  range  between  0  and  100. 

•  Exceeded  ‘max-elaborations*.  Proceeding  to  decision  procedure. 


Production  syntax 
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•  illegal  index  after  t. 

•  Constant  identifier  field  in:  An  identifier  field  of  an  augmentation  in  a  condition  must  be  a 
variable. 

•  Identifier  field  not  constant  or  variable  in:  An  identifier  field  of  an  augmentation  in  an  action 
must  be  a  constant  or  variable. 

•  Constant  object  field  in:  An  object  field  of  a  preference  in  a  condition  must  not  be  a  constant. 

•  Object  field  not  constant  or  variable  in:  An  object  field  of  a  preference  in  an  action  must  be  a 
constant  or  variable. 

•  Condition  not  linked  to  previous  conditions:  The  conditions  of  a  production  must  all  be  linked  to 
the  goal-contexts,  cither  through  augmentations  or  preferences. 

ctions 

•  Atomic  Action:  Actions  must  be  lists. 

•  Illegal  Action. 

•  Unconnected  actions  in  production:  All  variables  in  the  actions  of  a  production  must  either 
appear  in  the  conditions  or  be  linked  to  the  conditions  through  other  actions. 

•  Illegal  decide  in  production  type:  Ihe  decide  action  can  only  be  used  in  productions  of  type 
decide. 

•  Illegal  make  in  production  type:  Ihe  make  action  can  only  be  used  in  productions  of  type 
elaborate. 

•  Illegal  remove  in  Soar  production:  The  remove  action  can  not  be  used  in  productions. 

•  Illegal  modify  in  Soar  production:  The  modify  action  can  not  be  used  in  productions. 

•  Arguments  missing  from  make  action. 

•  W  rong  number  of  arguments  for  Tabstop. 

•  Illegal  argument  for  Tabstop. 

•  Cannot  be  called  at  top  level:  C  VI.  1.2. 

•  TABSTOP  can  not  be  called  at  the  top  level. 

•  W  rite  cannot  be  called  at  the  top  level. 

•  W  rite:  nothing  to  print. 

•  W'ritel  cannot  be  called  at  the  top  level. 
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•  Write  I :  nothing  to  print. 

«  Write!:  nothing  to  print. 

•  Write!  cannot  be  called  at  the  top  level. 

•  (S)PPWM  does  not  take  variables. 

•  C  annot  be  called  at  top  level:  BIND. 

•  Bind:  W  rong  number  of  arguments  to. 

•  Bind:  illegal  argument. 

•  CRLK:  Does  not  take  arguments. 

•  K.lliST:  Wrong  number  of  arguments. 

•  RJUST:  Illegal  value  for  field  width. 

•  TABTO:  W  rong  number  of  arguments. 

•  TABTO:  Illegal  column  number. 

Chunking 

•  No  chunk  was  built  because  there  were  no  actions. 

•  No  chunk  was  built  because  *max-chunk-conditions*  was  exceeded. 

•  No  chunk  was  built  because  no  conditions  had  a  class  in  ‘chunk-classes*. 
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1 1 .3.  Recovery  Hints 

Symptom  Probable  cause  Remedy 


A  Soar  rule  won’t  load; 
it  just  sits  there 

Certain  syntax  errors 
send  the  loader  into  an 
infinite  loop;  other  times 
the  loader  just  balks. 

Try  reloading  the 
rule:  also  check  for 
syntax  errors,  such  as 
missing  spaces  inside 
curly  brackets. 

While  loading  in  rules. 
Lisp  tries  to  evaluate 
a  condition. 

There  is  an  extra  close 
parenthes i s  . 

Remove  the  extra 
parenthes  i  s . 

Two  goals  are  generated 
followed  by  a  message 
that  Soar  must 
terminate . 

1.  There  are  no  non-default 
p  roduct ions. 

2  .  The  initialization 

production  did  not  fire. 

1.  Load  in  productions 

2.  Make  sure  it  tests 
(gc  <g>  -tsupergoal  ) 

Many  of  the  productions 
just  loaded  do  not  fire 
when  they  should. 

Load  was  used  in  Interlisp. 

Reload  using  Soarload. 

Soar  uses  up  the  •max- 
elaborations*  number  of 
elaboration  cycles. 

A  rule  may  be  producing  a 
wm  element  which  enables 
the  rule  to  match  in  a  new 
way,  and  then  produce  a  new 
wm  element,  etc. 

Modify  the  rule  so 
that  none  of  its 
conditions  will  match 
any  of  its  actions. 

A  rule  matches,  but  is 
not  in  the  conflict  set. 

The  rule  is  prevented  from 
firing  by  refractory 
inhibition. 

A  good  (but  not 
perfect)  indicator  of 
refractory  inhibition 
is  when  (pi)  does  not 
print  any  wm  elements, 
but  just  returns  a 
number  one  greater 
than  the  number  of 
conditions  in  the  rule 

There  is  an  unexpected 
tie  between  the  new 
next  state  and  the 
initial  state. 

The  preference  for  the 
initial  state  included 
just  the  goal  and  problem 
space ;  thus  i t  app 1 ies 
regardless  of  the  state. 

Add  tstate  undecided 
to  the  preference 
for  the  initial 
state. 

There  is  an  unexpected 
tie  between  the  new 
next  state  and  the 
state  after  the  initial 
state. 

The  preferences  from  the 
supergoal  are  interfering 
wi th  the  subgoa 1 . 

Make  state  preferences 
sensitive  to  the  goal. 
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1 2.  Installing  Soar 


All  files  for  Soar  are  available  on  h.cs.cmu.edu  in  account  /usr/soar.  Hach  Lisp  dialect  has  a  separate 
directory  that  contains  all  of  the  files  necessary  to  run  Soar.  Common  Lisp = csoar,  Fnanz-Lisp=f soar. 
Interiisp—  isoar.  and  Z  eta- Lisp  =  /soar  Hach  of  these  directories  include  the  following  files: 

rcad.me  A  file  that  describes  how  to  run  this  dialect  of  Soar  and  an  index  of  all  the  files  in  this 

directory. 

default.soar  The  default  productions. 

eight.soar  The  Eight  Puzzle  productions. 

soar.load  A  load  file  that  will  load  in  all  files  necessary  to  run  A’oarcxcept  the  user  files.  (  This  is 

not  necessary  for  Fnanz-Lisp.) 

To  obtain  the  files  via  the  ARPA-net.  send  mail  cither  to  soar@h. cs.cmu.edu  or  John  Laird.  Xerox  PARC. 
3333  Coyote  Hill  Road.  Palo  Alto.  CA.  94304.  The  information  needed  to  KIP  the  files  will  be  sent  to  you. 
The  current  method  is  to  login  to  li.cs.cmu.edu  under  account  ftpguest  with  password  cmunix.  However,  this 
procedure  is  only  temporary  and  may  not  be  supported  for  very  long. 

In  all  systems,  the  first  step  in  executing  Soar  is  cither  loading  in  files  (3600.  l>machines.  and  Suns), 
executing  a  core  image  (Fnanz-Lisp).  or  executing  Lisp  with  a  suspend  file  ( Common  Lisp  on  a  Vax). 
Following  this,  the  default  productions  and  then  the  task  productions  should  be  loaded.  In  the  Interiisp 
version,  soarload  should  be  used  in  place  of  load  when  loading  Soar  files.  At  the  top-level  all  systems  use  the 
same  commands  like  run.  watch,  ppwm  and  print-stats.  In  the  Symbolics  3600.  Tl  Explorer,  and  Xerox 
D-machine  implementations,  hitting  any  character  while  Soar  is  running  will  cause  it  to  break  at  the  next 
production  cycle. 
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1 3.  Performance  Comparison 

Below  is  a  comparison  of  the  time  required  to  solve  a  simple  problem  in  the  Kight  Puzzle  on  different  Lisp 
systems  in  Version  4.  release  1.  Without  learning  for  the  Kight  Puz/le  it  took  143  decisions.  346  production 
cycles,  660  production  firings  and  3117  right-hand  side  actions.  All  runs  were  done  with  a  freshly  created 
virtual  memory.  All  times  arc  in  seconds.  I  he  systems  are  listed  in  order  of  increasing  elapsed  time.  No 
system  specific  optimizations  were  used  except  that  the  Franz-Lisp  runs  were  done  with  debugging 
information  disabled  (although  Soar  was  developed  under  Interlisp  so  it  is  more  tuned  for  the  Xerox 
machines).  Global  variables  were  declared  in  all  systems.  None  of  the  additional  declarations  that  are 
available  in  Common  Lisp  to  enhance  efficiency  were  used.  The  Sun  (run  on  December  18.  1985)  and  IBM 
R I  PC  (run  on  January  24.  1986)  runs  used  preliminary  compilers.  All  entries  of??  mean  that  cither  the 
statistic  was  unav  ailable  or  not  recorded  at  the  time  of  the  run. 


Machine 

Software 

Physical 

KlaDsed 

3600 

CPU 

GC 

Load 

Memory 

lime 

Ratio 

1'imc 

lime 

Factor 

Xerox  1132 

Interlisp 

8  Mbytes 

127 

1.08 

127 

off 

Symbolics  3600 

Zeta-Lisp 

4  Mbytes 

137 

1.0 

137 

off 

Xerox  1132 

Interlisp 

8  Mbytes 

149 

.92 

131 

18 

Symbolics  3600 

Zeta-Lisp 

4  Mbytes 

153 

.90 

137 

16 

Sun  3 

Common  Lisp 

8  Mbytes 

176 

.78 

171 

none 

IBM  R IPC 

Common  Lisp 

4  Mbytes 

210 

.65 

210 

•Y) 

-  1 

Vax  785-Unix 

Franz-Lisp 

8  Mbytes 

215 

.64 

182 

none 

TI  Explorer 

Common  Lisp 

8  Mbytes 

228 

.60 

228 

none 

TI  Kxplorer 

Zeta-Lisp 

8  Mbytes 

230 

.60 

230 

none 

Xerox  1 186 

Interlisp 

3.5  Mbytes 

348 

.39 

348 

off 

Vax  780-Unix 

Franz-Lisp 

4  Mbytes 

365 

.38 

298 

V. 

~  1 

Xerox  1109 

Interlisp 

3.5  Mbytes 

397 

.35 

397 

off 

Xerox  1186 

Interlisp 

3.5  Mbytes 

409 

.33 

366 

43 

Xerox  1109 

Interlisp 

3.5  Mbytes 

445 

.31 

402 

43 

Vax  785-Unix 

Franz-Lisp 

8  Mbytes 

470 

.29 

182 

V. 

-  3 

Dec-2060 

Common  Lisp 

8  Mbytes 

660 

.21 

196 

<Y) 

7? 

Vax  750-Unix 

Franz-Lisp 

4  Mbytes 

676 

.20 

495 

•Y) 

1 

I  he  fraction  following  the  elapsed  time  is  the  elapsed  time  for  the  given  machine  divided  by  the  elapsed  time 
of  the  3600.  I  he  performance  of  these  systems  may  be  different  for  other  programs  and  even  for  other  tasks 
in  Soar  that  have  different  runtime  charactensucs  than  the  Kight  Puzzle,  fhe  Kight  Puzzle  task  is  CPU 
intensive,  spending  most  of  its  time  matching  productions  to  working  memory  using  a  modified  version  of  the 
Ops5  Rete  matcher.  This  uses  simple  symbolic  computations,  such  as  equality  tests,  function  calls,  application 
of  functions  (apply),  and  list  manipulation.  I  here  is  no  number-crunching  of  integers  or  reals.  A  trace  of  the 
problem  solving  is  printed  to  the  terminal  or  console,  but  that  is  not  a  significant  factor  in  any  of  the  runs. 
I  here  is  no  tile  input  or  output  and  all  of  the  systems  had  enough  memory  so  there  was  no  within-process 
swapping. 


AH  of  the  single-user  workstations  had  sufficient  virtual  memory  so  that  garbage  collection  was  unnecessary. 
This  is  one  of  the  biggest  weaknesses  of  this  benchmark  because  different  types  of  garbage  collectors  are  used 
by  the  different  systems,  with  different  overheads.  For  very  long  runs,  garbage  collection  can  become  an 
important  factor  in  performance.  The  Xerox  machines  have  reference  garbage  collectors  while  the  3600  has 
an  ephemeral  garbage  collector,  both  which  are  used  incrementally  (they  do  not  wait  for  memory  to  get  low 
before  they  run),  so  runs  with  their  garbage  collectors  enabled  were  included.  The  elapsed  time  for  the  Xerox 
machines  with  their  garbage  collectors  disabled  is  less  than  their  CPU  times  using  garbage  collection  because 
the  CPU  time  includes  some  of  the  overhead  associated  with  garbage  collection  (such  as  updating  reference 
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14.  Soar  Bibliography 


Overview 

Laird.  J.  E..  Newell.  A..  &  Rosenbloom,  P.  S.  Soar:  An  Architecture  for  General  Intelligence.  1986.  In 
preparation. 

This  is  a  comprehensive  scientific  description  of  Soar  (Soar  4)  and  the  major  research  results. 


Laird.  J.  F...  Newell.  A..  &  Rosenbloom.  P.  S.  Proposal  for  Research  on  Soar  An  Architecture  for  General 
Intelligence  and  Learning.  1985. 

Ihis  proposal  provides  a  description  of  the  research  approach,  a  review  of  the  principal  research  results,  a 
survey  of  related  research,  and  proposed  research  for  the  period  1985- 1988. 

Major  Components 


Problem  Spaces 

Newell.  A.  Reasoning,  problem  solving  and  decision  processes:  Ihc  proniem  space  as  a  fundamental  category. 
In  R.  Nickerson  (Ed.),  Attention  and  Performance  I  III.  Hillsdale.  N.J  :  Frlbaum.  1980.  (Also  available 
asCMU  CSD  Technical  Report  Aug  19). 

I  his  paper  lays  out  the  foundations  behind  the  use  of  problem  spaces  for  all  goal-oriented  behav  lor. 

Universal  Weak  Method 

Laird.  J.  E„  and  Newell.  A.  A  Universal  Weak  Method)  lech.  Rep.  #83-141).  Carnegie-Mellon  Lniversity 
Computer  Science  Department.  June  1983. 

Discusses  the  weak  methods,  the  problem-space  hypothesis.  Soarl ,  what  a  universal  weak  method  is.  a 
particular  universal  weak  method,  and  a  demonstration  of  it  involving  the  use  of  many  methods  on  many 
tasks  in  Soarl.  ( Soarl  differs  significantly  from  the  version  of  Soar  described  in  this  manual.) 


Laird.  J.  H„  and  Newell,  A.  A  universal  weak  method:  Summary  of  results.  In  Proceedings  of  the  Eighth 
IJCAl.  1983. 

A  summary  of  the  longer  universal  weak  method  paper. 

Universal  Subgoaling 

Laird,  J.  E.  Universal  Subgoaling.  Doctoral  dissertation.  Carnegie-Mellon  University,  1983.  (Available  as 
Carnegie-Mellon  University  Computer  Science  l  ech.  Rep.  #84-129). 

Discusses  the  concept  of  universal  subgoaling.  updates  the  universal  weak  method  to  use  universal 
subgoaling,  presents  Soar2  and  some  demonstrations  of  it.( Soar2  differs  significantly  from  the  version  of  Soar 
described  in  this  manual.) 

Chunking 

Rosenbloom.  P.  S..  and  Newell.  A.  I  he  chunking  of  goal  hierarchies:  A  generalized  model  of  practice.  In 
R.  S.  Michalski.  J.  G.  Carhoncll.  &  I.  M  Mitchell  tl-.ds.).  Machine  I  earning:  An  Artificial  Intelligence 
Approach.  Volume  II.  Los  Altos.  CA:  Morgan  Kaufmann  Publishers.  Inc..  1986. 

Ihis  paper  lavs  out  the  foundations  for  goal-based  chunking  ( in  the  context  of  the  Xaps3  architecture). 


Laird.  J.  E..  Rosenbloom.  P.  S..  &  Newell.  A.  lowards  chunking  as  a  general  learning  mechanism.  In 
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Proceedings  of  AAAI-H4.  National  Conference  on  Artificial  Intelligence.  American  Association  for 
Artificial  Intelligence.  1984.  Available  in  Two  Soar  Studies,  (  l  ech.  Rep.  #85-110).  Carnegic-Mellon 
University  Computer  Science  Department,  January  1985. 

Ihis  paper  presents  the  first  results  from  implementing  chunking  in  Soar,  strategy  acquisition,  normal 
practice  speed-ups.  within-trial  transfer,  across-task  transfer,  and  knowledge  acquisition. 


Roscnbloom,  P.  S..  Laird,  J.  H„  Newell.  A..  Golding.  A..  Unruh.  A.  Current  research  on  learning  in  Soar.  In 
Proceedings  of  the  Third  International  Machine  I  earning  Workshop.  1985,  Skytop,  PA. 

This  paper  reviews  the  state  of  research  on  chunking  in  Soar  as  of  July.  1985.  It  includes  short  discussions  of 
work  on  analogy  and  generalization,  simple  abstraction  planning,  macro-operator  acquisition,  and  problem 
space  creation. 


l  aird.  J.  K..  Roscnbloom.  i\  S..  &  Newell.  A.  Chunking  in  Soar:  I'hc  anatomy  of  a  general  learning 
mechanism.  In  Machine  I. earning.  1986  1(1)  1 1-44. 

This  p.iper  presents  the  details  of  chunking  in  Soar.  It  includes  a  demonstration  of  chunking  based  on  Korfs 
Macro  Problem  Solver. 

Manuals 

Laird,  J.  K.  Soar  User's  Manual.  Version  4.  1986. 

The  manual  is  the  main  reference  for  using  Soar  4. 


Laird.  J.  E.  Soar  Technical  Manual.  1985.  In  preparation. 
The  manual  is  the  main  reference  for  the  Soar  software. 


Eorgy,  C.  L.  Ops5  Manual.  Computer  Science  Department,  Carnegie-Mellon  University.  1981. 

Soar  is  implemented  on  top  of  Ops5.  and  thus  inherits  many  aspects  of  it. 

Applications 

Rosenbloom.  P.  S..  l  aird,  J.  H„  McDermott.  J..  Newell,  A.,  &  Orciuch,  E.  R  1-Soar:  An  experiment  in 
knowledge-intensive  programming  in  a  problem-solving  architecture.  In  IEEE  Transactions  on  Pattern 
Analysis  and  Machine  Intelligence.  1985  7(5)  561-569.  This  also  appeared  in  Proceedings  of  the  IEEE 
Workshop  on  Principles  of  Knowledge- Based  Systems.  IKF.E  Computer  Society,  1984.  Available  in  Two 
Soar  Studies.  (  lech.  Rep.  #85-110).  Carnegie-Mellon  University  Computer  Science  Department. 
January  1985. 

This  paper  presents  the  first  attempt  at  expert  systems  in  Soar,  a  partial  reimplemcntation  of  Rl.  It  shows 
how  problem  solving  and  expertise  can  be  integrated,  and  how  chunking  can  acquire  expertise  from  problem 
solving. 
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Appendix  I 

Default  Search-Control  Productions 

Below  arc  the  default  productions  in  default.soar. 

(comment  ••••••  common  search-con t ro 1  productions  ••••••) 

(comment  all  operator  augmentations  of  the  problem  space  have 
acceptable-preferences  created  for  them) 

( sp  defaul t*make-al 1 -opera tors -accept able 
(gc  <g>  rproblem-space  <p>) 

(problem-space  <p>  roperator  <x>) 

-(preference  <x>  rrole  operator  tvalue  acceptable  t p rob  I em-space  <p>) 

--> 

(preference  <x>  rrole  operator  rvalue  acceptable 
rproblem-space  <p>)) 


(comment  if  an  operator  has  just  been  applied  to  a  state,  which  is 
detected  by  using  the  preference  created  for  that  state, 
reject  the  operator  for  that  state  so  it  will  not  be  reapplied 
in  the  future) 

(sp  default*no-operator-retry 

(gc  <g>  rproblem-space  <p>  rstate  <s2>) 

(preference  r0bject  <s2>  trole  state  rvalue  acceptable 
'goal  <g>  rproblem-space  <p>  rstate  <s> 
roperator  {  <>  undecided  <>  nil  <o>  }) 

--> 

(preference  <o>  rrole  operator  rvalue  reject 

rgoal  <g>  rprobiem-space  <p>  rstate  <s>)) 


(comment  if  there  is  a  reject-preference  for  the  current  state. 

make  an  acceptable-preference  for  the  prior  state  so  problem 
solving  can  backup) 


( sp  defaul t ‘backup- if -f a i led -state 

(gc  <g>  rproblem-space  <p>  rstate  <s>) 

(preference  <s>  rrole  state  rvalue  reject 
rgoal  <g>  rproblem-space  <p>) 

(preference  <s>  rrole  state  rvalue  acceptable 

rgoal  <g>  rproblem-space  <p>  rstate  {  <>  undecided  <>  nil  <n>  } 
roperator  <>  undecided) 

--> 

(preference  <n>  rrole  state  rvalue  acceptable 
rgoal  <g>  rproblem-space  <p>  rstate  < s >  > ) 
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(comment  ••••••  default  knowledge  for  tie  impasses  ••••••) 

(comment  if  the  problem  space  for  handling  the  subgoal  fails, 
signified  by  the  choices  none  impasse  below  it. 
make  a  worst-preference  for  each  tied  object) 

(sp  defaul t*problem-space-tie 

(gc  <g3>  trole  goa 1  tchoices  none  tsupergoal  < g 2 > ) 

(gc  <g2>  trole  problem-space  timpasse  tie  tsupergoal  (gl> 
t i tern  <p> ) 

--> 

(preference  <p>  trole  problem-space  tvalue  worst 
tgoal  < g  1  >  ) ) 

( sp  default*state-tie 

(gc  <g3>  trole  goal  tchoices  none  tsupergoal  < g 2 > ) 

(gc  <g2>  trole  state  timpasse  tie  tsupergoal  <gl>  ’item  <s>) 

(gc  <gl>  tproblem-space  <p>) 

--> 

(preference  <s>  trole  state  tvalue  worst 
tgoal  <gl>) ) 

(sp  defaul t*operator-tie 

(gc  <g3>  trole  goal  tchoices  none  tsupergoal  < g 2 >  i 

(gc  <g2>  trole  operator  timpasse  tie  tsupergoal  <gl>  titem  <o>) 

(gc  <gl>  tproblem-space  <p>  tstate  <"s>) 

--> 

(preference  <o>  trole  problem-space  tvalue  worst 
tgoal  <gl>  tproblem-space  < p > ) ) 


(comment  ••••••  conflict  impasses  ••••••) 

(comment  if  the  problem  space  for  handling  the  subgoal  fails, 
signified  by  the  choices  none  impasse  below  it. 
make  a  reject-preference  for  each  conflicted  object) 

(sp  default*problem-space-confl ict 

(gc  <g3>  trole  goal  tchoices  none  tsupergoal  <g2>) 

(gc  <g2>  trole  problem-space  timpasse  conflict  tsupergoal  <gl> 
t i tern  <p> ) 

--> 

(preference  <p>  'role  problem-space  tvalue  reject 
tgoal  <g I > ) ) 

(sp  defaul t*state-confl  ict 

(gc  <g3>  trole  goal  tchoices  none  tsupergoal  <g2>) 

(gc  <g2>  trole  state  timpasse  conflict 
tsupergoal  <gl>  titem  <s>) 

(gc  <gl>  tproblem-space  <p>) 

--> 

(preference  <s>  trole  state  ’value  reject 

tgoal  <gl>  tproblem-space  <  p  > ) ) 

(sp  defaul t*operator-conf 1  ict 

(gc  <g3>  trole  goal  ’choices  none  tsupergoal  <g2>) 

(gc  <g2>  trole  operator  timpasse  conflict  tsuperqoal  <gl> 

’  i  tern  <  o  > ) 

(gc  <gl>  ’problem-space  'p>  ’state  <s>) 

--> 

(preference  <o>  ’role  operator  ’value  reject 

tgoal  Cgi  /  ’prob I em- space  'p>  ’state  s^l) 


DEFAULT  SEARCH-CONTROL  PRODUCTIONS 


(comment  ••••••  no-choice  Impasses  ••••••) 

(comment  If  no  problem  spaces  are  available  for  the  top  goal, 
terminate  the  problem  solving  session  with  halt) 

(sp  default*goal-no-choices 

(gc  <g3>  rrole  goal  rchoices  none  tsupergoal  <g 2>) 

-(gc  <g2>  tsupergoal) 

--> 

(writel  (crlf)  ’no  problem  space  can  be  selected  for  top  goal.’) 
(writel  (crlf)  "soar  must  terminate.") 

(halt)) 


(comment  if  no  states  are  available  for  a  problem  space, 
and  there  is  no  problem  space  to  find  more. 
reject  that  problem  space) 

( sp  defaul t "problem- space -no -choices 

(gc  <g3>  trole  goal  rchoices  none  tsupergoal  -g2>) 

(gc  <g2>  trole  problem-space  rchoices  none  tsupergoal  <gl>) 

(gc  <gl>  rproblem-space  <p>) 

--> 

(preference  <p>  trole  problem-space  "value  reject  tgoal  <gl>)) 


(comment  if  no  operators  are  available  for  a  state. 

and  there  is  no  problem  space  to  find  more, 
reject  that  state) 

(sp  defau!t"state-no-choices 

(gc  <g3>  trole  goal  tchoices  none  tsupergoal  cg2>) 

(gc  <g2>  trole  state  tchoices  none  tsupergoal  <gl>) 

(gc  <gl>  rproblem-space  <p>  "state  <s>) 

--> 

(preference  <s>  trole  state  rvalue  reject 

tgoal  <gi>  tproblem-space  < p > ) ) 

(comment  if  no  changes  for  an  operator, 

and  there  is  no  problem  space  to  find  more, 
reject  that  operator) 

(sp  default*operator-no-choices 

(gc  <g3>  trole  goal  tchoices  none  tsupergoal  (gZ>) 

(gc  <g2>  trole  operator  t  impasse  no-change  tsupergoal  <gt>) 
(gc  <gl>  tproblem-space  <p>  "state  <s>  "operator  <o>) 

--> 

(preference  <o>  trole  operator  rvalue  reject 

"goal  <gl>  tproblem-space  <p>  "state  < s > ) ) 
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(comment 


selection  problem  space 


(comment  use  the  selection  problem  space  Tor  all  choice  multiple 

impasses,  make  it  worst  so  that  any  other  will  dominate) 

(sp  select*selection-space  elaborate 
(gc  <g>  ^choices  multiple) 

--> 

(preference  <p>  trole  problem-space  rvalue  acceptable  rgoal  <g>) 
(preference  <p>  ’ ro 1 e  problem-space  rvalue  worst  tgoal  <g>) 
(problem-space  <p>  'name  selection)) 


(comment  the  state  of  the  selection  problem  space  is  empty) 

(sp  select*create-state 

(gc  <g>  rproblem-space  <p>  rstate  undecided) 

(space  <p>  rname  selection) 

-  -  > 

(preference  <s>  'role  state  rvalue  acceptable 

rgoal  <g>  rprob 1 em- space  <p>  rstate  undecided)) 


( comment 


evaluate-object  operator 


(comment  create  an  evaluate-object  operator  for  each  tying  item 
in  selection  problem  space.  These  are  all  indifferent 
so  there  will  be  no  tie  between  them.) 

( sp  eval»select-evaluate 

(gc  <g>  rproblem-space  <p>  rstate  <s>  rsupergoal  <g2>  »item  <x>) 
(problem-space  <p>  rname  selection) 

- 2 

(operator  <o>  rstate  <s>  rname  evaluate-object  robject  < x > ) 
(preference  <o>  rrole  operator  rvalue  indifferent 
rgoal  <g>  rproblem-space  <p>  rstate  <S>  ) 

(preference  <o>  rrole  operator  rvalue  acceptable 
rgoal  <g>  rproblem-space  <p>  rstate  <s>  )) 


(comment  for  parallel  evaluation 

remove  this  comment  if  you  want  parallel  evaluation  of 
the  alternatives. 

(  sp  eval*paral lei -evaluate 

(gc  <g>  rproblem-space  rp>  rstate  <s>  rrole  operator  rsupergoal  <  g  2  > ) 
(problem-space  <p>  rname  selection) 

(preference  <ol>  rrole  operator  rvalue  acceptable 
rgoal  <g.>  rproblem-space  <p>  rstate  <s>) 

(preference  <o2>  rrole  operator  rvalue  acceptable 
rgoal  <g>  rproblem-space  < p>  rstate  <s>) 

(operator  <ol>  robject  <y>) 

(operator  <o2>  robject  (  <>  <y>  <x>  )) 

--  > 

(preference  <ol>  rrole  operator  rvalue  parallel 

rgoal  <g>  rproblem-space  <  p>  rstate  <s->  'reference  < o2 > ) ) ) 


\!  ‘Ok  H  \!'l  is' 
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(comment  create  evaluation  once  the  eval  operator  is  selected) 

(sp  eval'apply-evaluate 

(gc  <g>  tproblem-space  <p>  tstate  <s>  roperator  <o> 
trole  <role>  rsupergoal  <g2>) 

(problem- space  <p>  tname  selection) 

(gc  <g2>  tproblem-space  <p2>  tstate  <s2>  tdesired  <d>) 

(operator  <o>  'hum  evaluate-ob ject  tobject  <x>) 

--> 

(state  <s>  revaluation  <e>) 

(evaluation  <e>  tobject  <x>  tstate  <s>  roperator  <o>  tdesired  <d>) 
(operator  <o>  trole  <role>  revaluation  <e>  tdesired  <d> 

’supergoal  <g2>  tsuperproblem-space  <p2>  tsuperstate  < s 2 > ) ) 

(comment  reject  evaluate-ob ject  after  it  finished  in  selection  space) 

( sp  eval • re ject -eval uate-f in i shed 

(gc  <g>  tproblem-space  <p>  tstate  <s>  ’operator  <o>) 

(problem-space  <p>  tname  selection) 

(operator  <o>  ’name  evaluate-object  revaluation  <e>) 

(evaluation  <e>  t  <<  numeric-value  symbolic-value  >>) 

--> 

(preference  <o>  trole  operator  tvalue  reject  ’goal  <g> 
tproblem-space  <p>  tstate  < s > ) ) 
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(comment  if  two  objects  have  equal  evaluations  they  are  indifferent) 

( sp  eval ‘equal -eval - ind Iff erent -preference 

(gc  <g>  ‘problem-space  <p>  ‘state  <s>  ‘rote  <role>  tsupergoal  <g2>) 
(problem-space  <p>  ‘name  selection) 

(state  <s>  ‘evaluation  <el>  ‘evaluation  {  <>  <el>  <e2>  }) 

(gc  <g2>  ‘problem-space  <p2)  ‘state  <$2>  ‘desired  <d>) 

(evaluation  <el>  ‘object  <x>  ‘numeric-value  <v>  ‘desired  <d>) 
(evaluation  <e2>  ‘object  <y>  ‘numeric-value  <v>  ‘desired  <d>) 

--> 

(preference  <x>  ‘role  <ro)e>  ‘value  indifferent  ‘ reference  <y> 

‘goal  <g2>  ‘problem-space  <p2>  ‘state  <s2>)) 


(comment  generate  operator  preferences  based  on  their  evaluations  and  info 
as  to  whether  higher  or  lower  evaluations  are  better.) 

(sp  eval ‘prefer- h igher- evaluation 

(gc  <g>  ‘problem-space  <p>  ‘state  <s>  ‘role  <role>  ‘supergoal  < g 2  • ) 
(problem-space  <p>  ‘name  selection) 

(gc  <g2>  ‘problem-space  <p2>  ‘state  <s2>  ‘desired  <'d>) 

(state  <s>  ‘evaluation  <el>  ‘evaluation  {  <>  <elr  <e2>  }) 

(evaluation  <d>  ‘better  higher) 

(evaluation  <el>  ‘object  <ol>  ‘numeric-value  <v>  ‘desired  <d>! 
(evaluation  <e2>  ‘object  <o2>  ‘numeric-value  <  lv>  ‘desired  <d>) 

--> 

(preference  <o2>  trole  <role>  ‘value  worse  ‘reference  <ol> 

‘goal  <g2>  ‘problem-space  <p2>  ‘state  <s2>)) 

(sp  eval*prefer-lower-evaluation 

(gc  <g>  ‘problem-space  <p>  ‘state  <s>  trole  <role>  ‘supergoal  <g2>) 
(problem-space  <p>  ‘name  selection) 

(gc  <g2>  ‘problem-space  <p2>  ‘state  <s2>  ‘desired  <d>) 

(state  <s>  ‘evaluation  <el>  ‘evaluation  {  <>  <el>  }) 

(evaluation  <d>  ‘better  lower) 

(evaluation  <el>  ‘object  <ol>  ‘numeric-value  <v>  ‘desired  <d>) 
(evaluation  <e2>  ‘object  <o2>  ‘numeric-value  >  <v>  ‘desired  <d>) 

--> 

(preference  <o2>  ‘role  operator  ‘value  worse  ‘reference  <ol> 

‘goal  <g2>  ‘problem-space  <p2>  ‘state  <s2>)) 
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(comment 


productions  for  the  evaluation  subgoal 


(comment  copy  down  the  desired  and  create  the  appropriate  context, 
given  the  role  of  the  object  being  evaluated) 

(sp  aval "select -role- problem -space 

(gc  <g>  tproblem-space  undecided  tsupergoal  <g2>  tsuperoperator  <o2>) 

(gc  <g2>  ’operator  <o2>) 

(operator  <o2>  tname  evaluate-ob ject  trole  problem-space  ’object  <p>  tdesired  <d>) 
--> 

(gc  <g>  tdesired  <d>) 

(preference  <p>  trole  problem-space  ’value  acceptable  tgoal  <’g>)) 


( sp  eval*select-role-state 

(gc  <g>  tproblem-space  undecided  tsupergoal  <g2>  tsuperoperator  <o2>] 
(gc  <g2>  toperator  <o2>) 

(operator  <o2>  tname  evaluate-object  trole  state  tobject  <s> 
tsuperprob 1 em- space  tp>  tdesired  <d>) 

--> 

(gc  <g>  tdesired  <d>) 

(preference  <p>  trole  problem-space  tvalue  acceptable  tgoal  <g>) 
(preference  <s>  trole  state  tvalue  acceptable 

tgoal  <g>  tproblem-space  <p>  tstate  undecided) 

(preference  <s>  trole  state  tvalue  best 

tgoal  «.g>  tproblem-space  <p>  tstate  undecided)) 


( sp  eval"select-role-operator 

(gc  <g>  tproblem-space  undecided  tsupergoal  -g2>  tsuperoperator  <o2>) 
(gc  <g2>  toperator  <o2>) 

(operator  <o2>  tname  evaluate-object  trole  operator  tobject  <o> 
tsuperproblem-space  'p>  tsuperstate  <s>  ’desired  <d>) 

--> 

(gc  <g>  tdesired  <d>) 

(preference  <p>  trole  problem-space  tvalue  acceptable  tgoal  <g>) 
(preference  <s>  trole  state  tvalue  acceptable 

tgoal  <g>  tproblem-space  <p>  tstate  undecided) 

(preference  <o>  trole  operator  ’value  acceptable 
tgoal  <g>  tproblem-space  <p>  tstate  < s > ) ) 


(comment  reject  those  operators  that  are  not  being  evaluated  in  this  subgoal) 
( sp  aval* re ject -non- slot-operator 

(gc  <g>  tproblem-space  <p>  ’state  <s>  tsupergoal  <g2>  tsuperoperator  <o2>) 

(operator  <o2>  tname  evaluate-object  trole  operator  ’object  <o> 
tsuperstate  <s>) 

(preference  {  <>  <o>  <o3>  }  trole  operator  tvalue  acceptable 
tgoal  <g>  tproblem-space  <p>  ’state  <s>) 

(preference  <o3>  trole  operator  ’value  reject 
tgoal  <g>  ’problem-space  <p>  ’state  <s>)) 
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(comment  give  symbol-value  failure  to  an  operator  that  has  been  rejected 

during  evaluation  and  did  not  create  a  nee  state  and  reject  the  eval -operator) 

(sp  eval*failure-1f-reject-eval ing-operator 

(gc  <g>  'problem-space  <p>  'state  <s>  'operator  <o> 

'supergoal  <g2>  'superoperator  <o2>) 

(gc  <g2>  'problem-space  <p2>  'state  <s2>) 

(operator  <o2>  'name  evaluate-object  'role  operator 
'object  <o>  'superstate  <s>  'evaluation  <e2>) 

(preference  <o>  'role  operator  'value  reject 

'goal  <g>  'problem-space  <p>  'state  <s>  'operator  <o>) 

-(preference  'role  state  'value  acceptable 

'goal  <g>  'problem-space  <p>  'state  <s>  'operator  <o>) 

--  > 

(evaluation  <e2>  'symbolic-value  failure)) 

(comment  give  symbol-value  failure  to  an  operator 

that  produces  a  state  that  gets  rejected  in  the  subgoal) 

(sp  evalVailure-  if-reject-state 

(gc  <g>  'problem-space  <p>  'state  <s> 

'supergoal  <g2>  'superoperator  <o2>) 

(gc  <g2>  'problem-space  <p2>  'state  <s2>) 

(operator  <o2>  'name  evaluate-object  'evaluation  <e2>) 

(preference  <s>  'role  state  'value  reject 
'goal  <g>  'problem-space  <p>) 

--> 

(evaluation  <e2>  'symbolic-value  failure)) 


(comment  if  an  operator  leads  to  success  and  it  is  being 

tried  out  in  a  subgoal  to  evaluate  another  operator, 
give  that  second  operator  a  success  evaluation  also) 

(sp  eval*pass-back-success 

(gc  <g>  'problem-space  <p>  'state  <s>  'operator  <o>  'supergoal  <g2>) 
(problem-space  <p>  'name  selection) 

(operator  <o>  'name  evaluate-object  'evaluation  <el>  'desired  <eb>) 
(evaluation  <el>  'symbolic-value  success) 

(gc  <g2>  'superoperator  <o3>) 

(operator  <o3>  'name  evaluate-object  'evaluation  <e2>  'desired  <eb>) 

--> 

(evaluation  <e2>  'symbolic-value  success)) 
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(comment  If  an  operator  is  evaluated  to  be  lose  or  failure  for 
the  same  desired  as  the  supergoal, 
create  a  worst-preference  for  it) 

(sp  eval*failure-becomes-worst 

(gc  <g>  'problem-space  <p>  rstate  <s>  'operator  <o>  tsupergoal  <g2>) 
(problem- space  <p>  tname  selection) 

(gc  <g2>  tproblem-space  <p2>  rstate  <s2)  'desired  <d>) 

(operator  <o>  tname  evaluate-object  revaluation  <el>  tdesired  <d> 
trole  <role>  tobject  <ot>) 

(evaluation  <el>  tsymbol ic-value  <<  lose  failure  >>) 

--> 

(preference  <ol>  trole  operator  rvalue  worst 

tgoal  < g 2 >  tproblem-space  <p2>  rstate  <s2>)) 


(comment  if  an  operator  is  evaluated  to  be  success  for 
the  same  desired  as  the  supergoal, 
create  a  best-preference  for  it) 


■m 

$ 


( sp  aval ‘success -becomes -bes t 

(gc  <g>  tproblem-space  <p>  rstate  <s>  toperator  <o>  tsupergoal  <g2>) 
(problem-space  <p>  tname  selection) 

(gc  <g2>  tproblem-space  <p2>  rstate  <s2>  tdesired  <d>) 

(operator  <o>  tname  evaluate-object  revaluation  <el> 
tdesired  <d>  tobject  <ol>  trole  <role>) 

(evaluation  <el>  tsymbol ic-value  success) 

(preference  <ol>  trole  <role>  rvalue  best 

'goal  <g2>  tproblem-space  <p2>  'state  <s2>)) 
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SOAR  USER'S  MANUM. 


(comment  convert  state  augmentations  Into  evaluations) 

(sp  eval’state-to-symbol Ic-evaluatlon 

(gc  <g>  tp rob lem- space  <p>  tstate  <s>  tjuperoperator  <so>) 
(operator  <so>  tname  evaluate-object 
tevaluatlon  <e>  tdesired  <eb>) 

(state  <s>  r{  <<  success  failure  win  draw  lose  )  <svalue>  } 
--> 

(evaluation  <e>  tsymbol ic-value  <svalue>)) 

(comment  handle  state  augmentations  dealing  with  goal 
termination  for  the  top-level  goal) 

(sp  eval*detect-succe$s 

(gc  <g>  tstate  <s>  tname  <name>  tdesired  <eb>  -tsupergoal) 
(state  <s>  tjuccess  <eb>) 

--> 

(writel  (crlf)  "goal"  <name>  "achieved”) 

(halt)) 

(sp  evai*detect-win 

(gc  <g>  tstate  <s>  tname  <name>  -tsupergoal  tdesired  <eb>) 
(state  <s>  twin  <eb>) 

--> 

(writel  (crlf)  "game"  <name>  "won") 

(halt)) 

(sp  eval*detect-fai lure 

(gc  <g>  tstate  <s>  tname  <name>  -tsupergoal  tdesired  <eb>) 
(state  <s>  tfailure  <eb>) 

--> 

(preference  <s>  trole  state  tvalue  reject 
tgoal  <g>  tproblem-space  <p>)) 

(sp  eva1*detect-lose 

(gc  <g>  tstate  <s>  tname  <name>  -tsupergoal  tdesired  <eb>) 
(state  <s>  tiose  <eb>) 

--> 

(writel  (crlf)  "game"  <name>  "lost") 

(halt)) 


<eb>  ) 
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(comment  two  player  games  -  win  side  oside  lose) 

(sp  eval*move-side-to-eval 

(gc  <g>  tstate  <s>  tsuperoperator  <so>) 

(state  <s>  toside  <side>  t  <<  lose  win  >>) 

(operator  <$o>  'name  evaluate-object  revaluation  <e>) 

--> 

(evaluation  <e>  »side  <side>)) 

(sp  eval*winning-values 

(gc  <g>  rprob lem- space  <p>  'state  <s>  rsupergoal  < g  1  >  'operator  <o>) 
(problem-space  <p>  'name  selection) 

(gc  <gl>  'problem-space  <pl>  'state  <sl>) 

(state  <sl>  'side  <side>) 

(operator  <o>  'name  evaluate-object  'evaluation  <e>  'object  <ol>  'role  <role>) 
(evaluation  <e>  'symbolic-value  win  'side  <$ide>) 

--> 

(preference  <ol>  'role  <role>  'value  best 

'goal  <gl>  'problem-space  <pl>  'state  <sl>)) 

(sp  eval*winning-values2 

(gc  <g>  'problem-space  <p>  'state  <s>  'supergoal  <gl>  'operator  <o>) 
(problem-space  <p>  'name  selection) 

(gc  <gl>  'problem- space  <pl>  'state  <sl>) 

(state  <sl>  'oside  <side>) 

(operator  <o>  'name  evaluate-object  'evaluation  <e>  'object  <ol>  'role  <role>) 
(evaluation  <e>  'symbolic-value  lose  'side  <side>) 

--> 

(preference  <ol>  rrole  <role>  'value  best 

'goal  <gl>  'problem-space  <pl>  'state  :sl>)) 

(sp  eval*draw-values 

(gc  <g>  'problem-space  <p>  'state  <s>  'supergoal  <gl>  'operator  <o>) 

(problem- space  <p>  'name  selection) 

(gc  <gl>  'problem-space  <pl>  'state  < s 1 > ) 

(operator  <o>  'name  evaluate-object  'evaluation  <e>  'object  <ol>  'role  <role>) 
(evaluation  <e>  'symbolic-value  draw) 

-  -  > 

(preference  <ol>  'role  <role>  'value  indifferent 
'goal  <gl>  'problem-space  <pl>  'state  <sl>)) 
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(sp  eval*losing-values 

(gc  <g>  ’prob) em- space  <p>  ’state  <*>  ’supergoal  <gl>  ’operator  <o>) 
(problem-space  <p>  ’name  selection) 

(gc  <gl>  ’problem-space  <pl>  ’state  <sl>) 

(state  <sl>  roside  <s1de>) 

(operator  <o>  ’name  evaluate-object  tevaluation  <e>  ’object  <ot>  ’role  <role>) 
(evaluation  <e>  ’symbolic- value  win  ’side  <side>) 

--> 

(preference  <ol>  ’role  <role>  ’value  worst 

’goal  <gl>  ’problem-space  < p 1 >  ’state  < *  1 > ) ) 

(sp  eval*loslng-values2 

(gc  <g>  ’problem-space  <p>  ’state  <s>  ’supergoal  <gl>  ’operator  <o>) 

(problem- space  <p>  ’name  selection) 

(gc  <gl>  ’problem-space  <pl>  ’state  <sl>) 

(state  <sl>  ’side  <side>) 

(operator  <o>  ’name  evaluate-object  ’evaluation  <e>  ’object  <ol>  ’role  <role>) 
(evaluation  <e>  ’symbolic-value  lose  ’Side  <side>) 

-  -  > 

(preference  <ol>  ’role  <ro!e>  ’value  worst 

’goal  <gl>  ’problem-space  <pl>  ’state  < s  1  > ) ) 

(sp  eval*pa$s-back-win 

(gc  <g>  ’problem-space  <p>  ’state  <s>  ’supergoal  <g2>  ’operator  <o>) 
(problem-space  <p>  ’name  selection) 

(operator  <o>  ’name  evaluate-object  ’evaluation  <el>  ’desired  <eb>) 

(evaluation  <el>  ’symbolic-value  win  ’side  <side>) 

(gc  <g2>  ’superoperator  <o3>) 

(operator  <o3>  ’name  evaluate-object  ’evaluation  <e2>  ’desired  <eb> 

’superstate  <s4>) 

(state  <s4>  ’oside  <side>) 

--  > 

(evaluation  <e2>  ’symbolic-value  win  ’side  <side>)) 

(sp  eval*pas$-back-win2 

(gc  <g>  ’problem- space  <p>  ’state  <s>  ’supergoal  <g2>  ’operator  <o>) 

(problem- space  <p>  ’name  selection) 

(operator  <o>  ’name  evaluate-object  ’evaluation  <el>  ’desired  <eb>) 

(evaluation  <el>  ’symbol  ic-value  lose  ’ side  <side>) 

(gc  <g2>  ’superoperator  <o3>) 

(operator  <o3>  ’name  evaluate-object  ’evaluation  <e2>  ’desired  <eb> 

’superstate  <s4>) 

(state  <s4>  ’side  <side>) 

--> 

(evaluation  <e2>  ’symbolic-value  win  ’side  <side>)) 
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(comment  ••••••••••••••••  operator  subgoal  ing  •*•••••••••••••• 

there  are  two  ways  to  do  operator  subgoal 

just  pass  down  most  recent  operator,  or  pass  down  all  of  them 
this  implementation  passes  down  just  the  super  operator  as  the 
desired  -  uncomment  opsub*go-for-it2  if  you  want  all  supergoals 
to  be  included) 

(comment  make  the  super-problem  space  the  default 

when  there  is  a  no-change  for  the  operator) 

( sp  opsub*try-operator-subgoal ing 

(gc  <g>  t impasse  no-change  trole  operator 

rproblem-space  undecided  rsupergoal  <g2>) 

(gc  <g2>  rproblem-space  <p2>) 

--> 

(preference  <p2>  tgoal  <g>  trole  problem-space  rvalue  acceptable) 
(preference  <p2>  tgoal  <g>  trole  problem-space  rvalue  worst)) 


(comment  if  the  superproblem-space  is  selected  as  the 

current  problem  space  then  operator  subgoal  ing 
is  being  used  so  select  the  superstate  - 
the  superoperator  becomes  the  desired) 

(sp  opsub*go-for-it 

(gc  <g>  rproblem-space  <p>  rstate  undecided 

r impasse  no-change  trole  operator  rsupergoal  <g2>) 
(gc  <g2>  rproblem-space  <p>  rstate  <s>  'operator  <o>) 

--> 

(gc  <g>  rname  operator-subgoal  rdesired  <o>) 

(preference  <s>  trole  state  rvalue  acceptable 

rgoal  <g>  rproblem-space  <p>  rstate  undecided)) 


(conmient  pass  down  all  super  operator  subgoals  as  well 
(sp  opsub*go-for-it2 

(gc  <g>  rproblem-space  <p>  rstate  undecided 

rimpasse  no-change  trole  operator  tsupergoal  <g2>) 
(gc  <g2>  rproblem-space  <p>  rstate  <s>  rdesired  <o>) 

--> 

(gc  <g>  rdesired  <o>))  ) 


(comment  don't  select  the  operator  for  the  initial  state  that  we  are 
subgoal ing  on) 

(sp  opsub*reject-opsub*operator 

(gc  <g>  »name  operator-subgoal  rproblem-space  <p>  rstate  <s>  rdesired  <o>) 

(preference  <s>  trole  state  rvalue  acceptable 

rgoal  <g>  rproblem-space  <p>  rstate  undecided) 

--> 

(preference  <o>  trole  operator  rvalue  reject 

rgoal  <g>  rproblem-space  <p>  rstate  <s>)) 
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(comment  select  superoperator  for  all  new  states) 

(sp  opaub*select-opsub*operator 

(gc  <gl>  'name  operator-subgoal  'problem- space  <p>  'state  <s>  'desired  <o>) 
--> 

(preference  <o>  'role  operator  'value  acceptable 
'goal  <gl>  'problem-space  <p>  'state  <s>) 

(preference  <o>  'role  operator  'value  best 

'goal  c g  1  >  'problem-space  <p>  'state  <$>)) 


(comment  if  superoperator  applied  to  a  state  then  success 
we  make  a  preference  for  the  state  it  created) 

( sp  opsub*detect-direct-opsub- success 

(gc  <g0>  'problem-space  <p>  'state  <s>  'operator  <o> 

'supergoal  <gl>  'name  operator-subgoal) 

(gc  <gl>  'problem-space  <p>  'state  <s2>  'operator  <-o>) 
(preference  <ns>  'role  state  'value  acceptable 

'goal  <g0>  'problem-space  <p>  'state  <s>  'operator  <o>) 

--> 

(preference  <ns>  'role  state  'value  acceptable 

'goal  <gl>  'problem-space  <p>  'state  <s2>  'operator  <o>)) 

(comment  if  there  is  an  evaluation  subgoal  within 

an  operator  subgoal  and  the  operator  being 
subgoaled  on  is  applied  -  success) 

(sp  opsub'detect- indirect-opsub-success 

(gc  <gl>  'name  operator-subgoa I  'supergoal  <g2>) 

(gc  <g2>  'problem-space  <p>  'state  <s2>  'operator  <o>) 

(gc  <g0>  'problem-space  <p>  'state  <s>  'operator  <o> 

'desired  <o>  'superoperator  <so>) 

(operator  <so>  'name  evaluate-object) 

(preference  <ns>  'role  state  'value  acceptable 

'goal  <g0>  'problem-space  <p>  'state  <s>  'operator  <o>) 

--> 

(state  <s)  'success  < o> ) ) 


(comment  if  the  operator  being  subgoaled  on  is  the  current 
operator  and  a  no-change  subgoal  is  created  for  it 
then  reject  it  In  the  subgoal) 

(sp  opsub'reject-double-op-sub 

(gc  <gl>  'name  operator-subgoal  'desired  <o>) 

(gc  {  O  <gl>  <g3>  }  'name  operator-subgoal) 

(gc  <g3>  'supergoal  <g 4 > ) 

(gc  <g4>  'problem-space  <p>  'state  <s>  'operator  <o>) 

-(gc  'supergoal  <g3>) 

-  -  > 

(preference  <o>  'role  operator  'value  reject 

'goal  <g4>  'problem-space  <p>  'state  <s>)) 


\l  KO'*  -»Rt  IS!  .  W 


SUMMARY  OK  FUNCTIONS  AND  VARIABLES 


99 


Appendix  II 

Summary  of  Functions  and  Variables 


*chuak-all-paths*  Controls  multiple  chunks  from  different  paths:  nil 

•cbuok-classes*  SP  classes  that  must  appear  in  a  chunk  for  t(  to  be  built:  (state) 

•chunk-free- problem -spaces*  Names  of  problem  space  not  to  chunk:  ( ) 

•chunks*  Names  of  chunks  built:  ( ) 

•nax-cbaak-coaditiOK*  The  maximum  number  of  conditions  allowed  in  a  chunk:  200 
•max-elaborations*  The  maximum  number  of  elaboration  c>cles  before  a  decision:  100 

*max-recurxe*  Depth  of  look  ahead  used  by  ordering  scheme:  2 

•sp-classes*  Association  list  of  SP  and  P  classes:  (tec  goal-context-info)  ) 

•spo-default-depth*  Default  depth  that  spo  prints:  I 

•subftoal-labs*  If  T.  Watch  0  trace  will  tab  in  subgoals:  T 

•warning*  If  nil.  warnings  wilt  not  be  printed:  T 

•watch-free-problem-spaces*  List  of  problem  space  names  noi  to  trace:  ( ) 


back-trace 

cs 

d 

decide-trace 

excise 

excise-chunks 

init-context 

mil-soar 

last-chunk 

learn 

list-chunks 

make 

matches 

multi-attributes 

P 

pbreak 

P< 

Pgs 

Pm 

po 

pop-goal 

ppwm 

print-stats 

ptrace 

restart-soar 

ran 

snake 

smatebes 

soarload 

«P 

spm 

spo 

spop 

spr 

sppwm 

sremoxe 

swra 

trace-attributes 
unpbreak 
unp  trace 
user- select 
watch 


Print  out  those  conditions  and  productions  that  lead  to  the  action:  (back -trace  00014) 

Pnnt  the  conflict  set:  (cs) 

Run  N decision  cycles:  (d  5) 

Trace  the  decision  procedure,  l  or  nil:  (decide-irace  ml) 

Remove  a  production  from  production  memory  :  (excise  eighl'crcate-sutel 
Excise  all  chunks:  (excise-chunks) 

Initialize  the  top  context:  (init-context  pi  si  ol) 

Clear  out  working  memory:  unit-soar) 

Print  out  most  recently  built  chunk  in  SP  format:  (last-chunk) 

Control  chunking:  (learn  off  always  print) 

Pnni  out  chunks  in  SP  format:  (list-chunk) 

Add  element  to  working  memory:  (make  state-info  ndentifier  s02  ) 

Show  all  working-memory  elements  that  match  a  production:  (matches  eight ‘create- suie  l 
Declare  some  attributes  of  some  classes  to  be  sets:  ( multi-attributes  ((state  binding  4») 
Define  a  production,  (p  eighi*create-state  (goal-context-info  ndenufier  <g>  >  ) 

Break  after  production  fires  or  context  change:(pbreak  cvaluate-ob)ect  eighi*creatc-sutc> 
Print  the  Nth  partial  instantiation  of  a  production:  (pi  eight’crcaie-staic  )) 

Prim  the  goal-context  suck:  (pgs) 

Print  production  in  P  format:  (pm  eight*create-sute) 

Print  all  augmenuuons  of  object:  (po  G0033) 

Terminate  all  goal  and  its  subgoals:  (pop-goal  g004$) 

Preuypnnt  working-memory  elements:  tppwm  state-info) 

Print  sutisucs  from  a  run:  tpnnt-stats) 

Trace  a  production,  object  or  working-memory  element:  (ptrace  eight*creaie-sute> 

Clear  out  production  memory  and  working  memory:  (resurt-soar) 

Run  N  productions  cycles:  (run  100) 

Add  element  in  SP  format  to  working  memory:  (smake  suie  s02  »av  3) 

Display  part  of  production  that  matches:  tsmatehes  eight’create-sute) 

Load  in  productions,  especially  for  D-machines:  (soarload  default  soar) 

Define  a  production  in  SP  formal:  (sp  eight*create-sute  (gc  <g>  )  ) 

Print  production  in  SP  formal:  (spm  eighi*ereaie-sute) 

Prim  all  augmenuuons  of  objects  in  SP  formal  to  given  depth:  (spo  00003  2) 

Print  all  preferences  of  objects  in  SP  format  to  given  depth:  ispop  G0003  2) 

Print  in  SP  format  of  whatever  us  given  as  an  argument:  (spr  00003) 

Prettypnm  working-memory  elements  in  SP  format:  (ppwm  siate-infot 
Remove  working-memory  element  with  given  cime-tag:  (sremove  33) 

SP  pnnt  the  object  in  the  identifier  field  of  the  element  with  the  ume-iag:  tswm  454) 

Will  trace  the  attributes  of  the  classes:  itrace-attnbutes  ((operator  module))! 

Remove  a  breakpoint  nil  removes  all  breaks:  (unpbreak  selection! 

Removes  all  traces  set  by  ptrace:  (unpiracel 

Change  how  indifferent-preferences  are  handled  first,  ml  =  random  T  =  user.  (3  selection  I) 
Control  tracing,  -1.0.  5.  1.  I  5  2 1 higher  =morei:  iwatchO) 

Pnnt  working-memory  elements  *uh  given  time- tags:  iwm  434  455) 
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•chunks*  61.  74 
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•max-elaborations*  61 
*max-recurse*  61 
*ops5 -actions*  16 
•sp-classes*  8.  61 
•spo-default -depth*  62.  68  69 
*subgoal-iabs*  62.65,67 
*iracep-lisi*  66 
•warning*  62 

•watch-frec-problem-spaces*  62 

<  12 
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«  »  45 
<=  12 
<>  12 

<>  undecided  17.  38 

=  12 

>  12 
>=  12 
»  12 

'attribute  8 

'better  29.  51.  54 

'desired  27.28.29.30.48  49 

'draw  32 

'evaluauon  27.  31 

'failure  32 

'identifier  8 

'lose  32 

'name  27.44 

'numeric-value  28.  31 

'object  27 

'operator  28 

'role  27 

'state  27.  28 

'success  32. 49 

'supergoal  27 

'superproblem-space  27 

'superstate  27 

'symbolic-value  28  31 

'symbolic-value  failure  29.  30 

'symbolic-value  success  29  31 

'symbolic-value  win  31 

'value  8 

'win  32 

\ccept  14 

Vccepiable  prefercnce  10  25 
Always  T3 
Attribute  8 
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Augmentauons  8 

Back-trace  69 
Best-preference  29 
Bind  13 
Bottom-up  73 
Bottom-up  chunking  3$ 

Call2  14 

Candidate  results  59 
Chunk  conditions  35 
Chunking  35 
Class  7 

Common  Lisp  79 
Compute  14.  31 
Conflict  23 
Conflict  impasse  22 
Conflict  impasses  25 
Conjunctions  13 
Conjunctive  negations  17 
Crlf  15 
CS  67 

D  63 
Decide  11 
Decide- trace  66 
Decision  1 1 

Decision  procedure  11.19 

Decision“gather-preferences  67 

Default*backup-if-failed-state  25. 85 

Default ‘goal-no-choices  26.  87 

Default’make- all-opera tors-acceptable  25. 45. 85 

Default’no-operator-  retry  25.85 

Default“opera  tor-conflict  25.86 

Default“operator-no-choices  26.87 

Default  “operator-tie  25.86 

Default*problem-sp»'~-conflict  25.86 

Default*pn>blem-space-no-choices  26. 87 

Default*problem -space- ue  25.86 

Default*state-confIia  25.86 

Default*state- no- choices  26.87 

Default“state-lie  25.86 

Defaultsoar  27.79 

Desired  23 

Desired  state  48 

Detect-candidate  59 

Detect-op  1-success  59 

Disjunction  12. 45 

Draw  28 

Duplicate  conditions  37 

Fight  Puzzle  41 
F.ight*acceptable  45 
Fight“copy-uncharged  47 
Eight“create-new-state  46 
Eight*detect-success  48 
Fighi“cval-state-pius-one  54 
Eight’miual-desired-states  50 
Fight  “start  50 
Fight*worst-undo  53 
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Elaborate  1 1 
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Errors  75 

r  Eval*appl> -evaluate  28.  89 

►  Eval’detect- failure  32.94 

Eval’detect-lose  32. 94 
Eval’detect-success  32.  94 
Eval’detect-win  32. 94 
F.val*draw-values  30  95 
Eval*equal-eval- indifferent- preference  29. 90 
Kval’failure-becomes-worst  29  91 
E'»al*failure-if-reject-evaling-operaior  30. 92 
Fval’failure-if-reject-suie  30  92 
FvaHosing-values  30.  % 

FvaHosing-valucs2  30  96 
Evarmove-side-to-eval  30.  95 
Eval’parallel-evaluaie  27.  88 
Fval*pass-back-suctxrss  31  92 
FvaTpass-back-win  31% 

1  vai*pass  back-*m2  31% 
F.val*prefer-higher-evaluation  29.  51.  90 
Eval'prefer-lower-esaluation  29.  90 
E>al*reject-evaluate-finished  28.  89 
Fval’reject-non-slot-operator  30.91 
Eval*seleci-evaluaie  27.  88 
Eval'select-role-operator  30.  91 
Evai*select-role-problem-space  30. 91 
Eval’selea-role-sttte  30.91 
Eval*state-to-symbolic-eviluation  32. 94 
Eval*success-becomes-best  29.  93 
Fval*winning-values  30. 95 
Fval*winning-values2  30  95 
Evaluate- object  26.  27.  28.  30 
Evaluauon  27.  30.  54 
Excise  73 
Excise-chunks  74 
Extraneous  conditions  37 

Failure  28 
Fields  8 
Franz-lasp  79 

Garbage  collection  24 
Goal  detection  47 
Goal  termination  24 
Goal-context  9. 62.  63 
Goal-context-info  8. 9,  23.  38  .  60 
Goal-context-stack  19,  22, 60 

H  cs  emu  edu  79 
Halt  14 
Help  78 
Hints  ’8 

Identifier  8 
Impasse  23 
Info  8 

Init-context  50. 62 
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Imt-soar  SO.  ft?,  ft  I 
Initial  slate  10 
Intcrlisp  79 
Item  23 


last-chunk  74 
learn  73 
I  ist-chunks  74 
lose  28 


Make  14.71 
Matches  ft*) 

Monitoring  states  S2 
Monolomc  operator  4h 
Mulli-attnbuies  SI. h3 
Multi-choice  impasses  25 


Name  8 

Negated  conditions  13,17.3ft 
Never  71 
No-change  2.3 
No-change  impasse  hO 
No-change  impasses  26 
No-choice  impasses  2ft 
Non-monoiomc  operator  4ft 
Nopnnt  73 
Sols  3X 

Numeric  evaluation  28.  3 1 


Object  7.8 
Off  73 
On  73 

Operator  application  4ft 
Operator  creation  45 
Operator  implementation  59 
Operator  instantiation  2ft 
Operator  subgoaling  2ft.  32 
Ops5  7.  15 

Opsub’deteci-direct-opsub-success  33. 98 
Opsub*detect-indircct-opsub-success  33. 98 
Opsub*go-l'or-il  32.97 
Opsub*go-for-it2  97 
Opsub*re|ect-double-op-sub  33  98 
Opsub*rcject-opsub*opcrator  12  97 
Opsub*sclect-opsub*operator  12.  98 
Opsub’iry-opcrator-subgoaling  '2. 97 
Ordering  conditions  38 
Ovcr-generali/ation  18 


P  11.72 

Parallel  operators  10.  r  hO 

Parallel  preference  M) 

Pbrenk  64 

WiS  ftO.  65  ft7 

PI  70 

PM  69 

PO  68 

Pop-goal  T? 

PPWM  6? 

Preference  29  19 
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Print  73 
Print-stats  70 
Prior  operator  10 
Prior  state  10 
Production  I L 
Production  acuons  13 
Production  conditions  1 1 
Production  functions  1 3 
Production  instantiation  1 1 
Ptrace  66 

Read  me  79 
Reference  10 
Refractory  inhibition  38 
Reject-preference  25 
Rejection  23 
Rejection  impasses  26 
Restart-soar  62 
Rete  network  38 
Role  9,  10.  23 
Run  63 

Search  control  25.53 

Select*creatc-state  26.  88 

Sclect*selection-space  26. 88 

Selection  problem  space  25  26 

Smake  15.  72 

S  matches  69 

Soar  load  79 

Soarload  63 

SP  8.11.15.72 

SPM  69 

SPO  68 

SPOP  69 

SPPWM  68 

SPR  67 

Sremove  72 

States  41 

Subgoal  creation  23 
Subgoals  23 
Success  28 
Supergoal  24 
Superoperator  24  60 
SWM  68 

Symbolic  evaluation  28.31 
Symbolics  3600  79 

Tabstop  14.  52 
fabto  15.52 
Tic-Tac-roe  28 
Tie  23.31 
Tie  impasse  22 
Tie  impasses  25 
Time-tags  1  b5  68.  69 
Trace  66.  100 
Trace-attnbutes  53  65 
Tracing  55 

Two-player  games  28.29 
Undecided  9 
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Warnings  75 

Watch  65 
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